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1.  SCOPE 

1.1  Identification.  This  specification  establishes  the  functional  requirements  for  the 
Advanced  Rotary  Wing  Aircraft  (ARWA)  Simulator  System  (SS). 

1.2  Purpose.  This  document  is  one  volume  of  a  five  volume  specification  that  defines 
the  requirements  for  the  ARWA  Simulator  Subsystem.  This  volume  specifically  defines 
the  requirements  for  the  Simulator  System  Module  (SSM). 

1.3  Introduction.  The  ARWA  SS  provides  the  capability  to  engage  in  simulated  war 
fighting  exercises  within  the  Distributed  Interactive  Simulation  (DIS)  environment  for  the 
purpose  of  rapidly  exploring  tactics,  doctrine  and  combat  system  development  issues.  The 
ARWA  SS  consists  of  a  number  of  subsystems  including  an  ARWA  Simulator  subsystem, 
a  Session  Manager  subsystem,  a  Mission  Planning  subsystem,  an  After  Action  Review 
subsystem,  a  Semi-automated  Forces  subsystem,  an  Operational  and  Logistics  and  Support 
subsystem,  and  a  Development  Subsystem.  Ihese  subsystems  communicate  via  a  DIS 
based  Loc^  Area  Network  (LAN).  The  basic  architecture  for  the  ARWA  SS  is  shown  in 
Figure  1.3-1. 


ARNVAftSDISCeU. 


Figure  1.3-1  ARWA  Simulator  System  Architecture 
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The  ARWA  Simulator  Subsystem  consists  of  a  number  of  manned  simulation  devices 
which  are  capable  of  being  reconfigured  between  AH-64D  and  RAH-66  rotary  wing 
aircraft.  The  simulation  devices  are  real-time,  software  intensive,  network  interoperable 
simulators  capable  of  supporting  both  hardware  and  software  reconfiguration  to  the  aircraft 
models.  The  ARWA  simulator  devices  simulate  the  aircraft  functions  needed  to  move, 
shoot,  communicate,  rearm,  and  resupply,  to  the  level  of  fidelity  defined  in  this 
speciHcation.  The  software  simulation  is  data  driven  to  provide  easy  access  to  critical 
parameters  for  modification  purposes  in  an  experimentation  environment.  The  basic 
architecture  of  the  ARWA  Simulator  subsystem  is  shown  in  Figure  1.3-2.  This 
architecture  is  based  on  the  Modular  Simulator  System  (MSS)  design. 


Figure  1.3-2  ARWA  Simulator  Subsystem  Architecture 
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The  SSM,  shown  in  Figure  1.3-3,  is  one  of  three  major  components  in  an  ARWA 
simulator  device.  The  SSM  component  provides  the  aircraft  simulations  for  flight 
dynamics,  flight  controls,  propulsion,  navigation/communication,  sensors,  aircraft 
survivability  equipment  (ASE),  weapons,  and  associated  simulator  support  systems 
including  physical  cues,  environment,  and  simulator  control. 


Figure  1.3-3  ARWA  Simulator  System  Module  Architecture 
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2.  APPUCABLE  DOCUMENTS 

2.1  Government  Documents.  The  following  documents  of  the  exact  issue  shown  form 
a  part  of  this  specification  to  the  extent  specified  herein.  In  the  event  of  conflict  between 
the  documents  referenced  herein  and  the  contents  of  this  specification,  the  contents  of  this 
specification  shall  be  considered  a  superseding  requirement 

PMT-90-W008  Statement  of  Work,  Rotary  Wing  Aircraft  (RWA) 

Experimental  AIRNET  Simulators 

A'lTXJ'TDS-SM  Memorandum  for  PM  TRADE,  5  June  1991 ,  Captain  Major 

MIL-STD-1815A  1983  Ada  Programming  Language 

MIL-STD-1777  Internet  Protocol  Specification 

MIL-T-23991  Training  Devices,  Military;  General  Specification  for 

MIL-STD-4S4  Standard  General  Requirements  for  Electronic  Equipment 

MIL-STD-882  System  Safety  Program 

MIL-STD-1472  Human  Engineering  Design  Criteria  for  Military  Systems, 

Equipment  and  Facilities 

FED-STD-595  Colors 

MIL-H-46855  Human  Engineering  Requirements  for  Military  Systems, 

Equipment  and  Facilities 

MIL-STD-483  Configuration  Management  Practices  for  Systems, 

Equipment,  Munitions  and  Computer  Programs 

2.2  Non-Government  Documents.  The  following  documents  of  the  exact  issue  shown 
form  a  part  of  this  specification  to  the  extent  specified  herein.  In  the  event  of  conflict 
between  the  documents  referenced  herein  and  tl^  contents  of  this  specification,  the  contents 
of  this  specification  shall  be  considered  a  superseding  requirement 

ANSI  X3. 148-1988  FDDI-Physical  Layer  Protocol 

ANSI  X3. 166- 1989  FDDI-Physical  Layer  Medium  Dependent 

ANSI  X3. 139- 1987  FDDI-Token  Ring  Media ._.  Control 

ANSI  X3T9.5/84-49  FDDI-Station  Management  Rev  5.0 

draft 

D567-30991  ADST  Rotary  Wing  Aircraft,  Step  1  Final  Report 

IEEE  802.2  IEEE  Logical  Link  Control  Specification 

IST-CR-93-15  Proposed  IEEE  Standard  Draft,  Standard  for  Information 

Technology  -  Protocols  for  Distributed  Interactive 
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Simulation  Applications,  Version  2.0,  Third  Draft, 
May28,1993 

PEI  89-103  Rev  3.4  Xpress  Transfer  Protocol  for  draft  copy  -  XTP  Protocol 

Definition  Protocol  Engines,  Inc.  Santa  Barbara,  CA 

S49S- 10400  System/Segment  Specification  for  the  Generic  Modular 

Simulator  System 

7S4- 1985  IEEE  Floating  Point  Specification 

Statement  of  Work,  Advanced  Rotary  Wing  Aircraft 
(ARWA)  Simulator  System 


3.  REQUIREMENTS 

3.1  System  Definition.  This  specification  defiitos  the  requirements  for  the  development 
and  test  of  the  Advanced  Rotary  Wing  Aircraft  (ARWA)  Simulator  System  (SS).  This 
System  is  intended  to  provide  the  capability  to  engage  in  simulated  war  fighting  exercises 
on  the  Batdefield  Distributed  Simulation-Development  (BDS-D)  network  for  the  purposes 
of  rapidly  exploring  current  and  emerging  tactics,  doctrine,  and  combat  development 
issues,  llie  ARWA  SS  shall  consist  of  two  simulator  stations  (ARWA  devices),  with  each 
station  capable  of  being  reconfigured  between  an  AH-64D  and  an  RAH-66,  a  Simulation 
Manager  station,  a  Management  Command  and  Control  station,  a  Data  Base  Maintenance 
station  and  a  Software  Maintenance  station.  Each  simulator  station  shall  allow  critical 
experimental  parameters,  listed  in  Appendix  B,  to  be  changed  without  reprogramming. 

3.1.1  Missions.  Each  of  the  ARWA  devices  shall  be  capable  of  performing  the  tasks 
identified  in  the  following  paragraphs  as  applicable  to  each  configuration. 

3. 1.1.1  Flight  Operations.  Flight  operations,  tar  j  and  procedures  shall  be 
simulated  and  performable  in  the  ARWA  devices  to  the  level  of  fidelity  defined  herein. 

3. 1 . 1 . 1 . 1  Ground  Operations.  Ground  operations  shall  include  tactical  resupply  and 
rearming.  Ground  operations  do  not  include  engine  start,  engine  run-up,  engine  and 
aircraft  shutdown.  Manual  mission  loading  by  keyboard  entry  or  electronic  media  loading 
shall  be  supported.  High  fidelity  taxi  capabilities  are  not  required. 

3. 1.1. 1.2  Takeoff  and  Landing.  Simulation  of  the  transition  from  the  ground 
environment  to  flight  and  from  flight  to  the  ground  environment,  including  aerodynamic 
ground  effects  shall  be  provided. 

3. 1.1. 1.3  Specific  Flight  Operations.  The  ARWA  devices  shall  provide  the  capability 
to  simulate  low  level,  contour,  map  of  the  earth,  masking  and  unmasking,  and  hovering 
flight  to  the  level  of  Edelity  defined  in  the  System  functional  requirements  portion  of  this 
specification,  paragraph  3.1.4. 

3. 1.1.2  Mission  Specific  Operations.  The  ARWA  devices  shall  simulate  the  aircraft 
functions  needed  to  move,  shoot,  communicate,  rearm,  and  resupply,  to  the  level  of  fidelity 
defined  herein. 

3. 1.1.3  Simulator  Control  Requirements.  The  Instructor/Operator  Station  (lOS) 
segment  shall  control  the  system  modes  ad  states  as  described  in  paragraph  3.1.3,  shall 
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monitor  simulation  parameters  as  deHned  in  Appendix  B,  and  shall  control  timing  and 
synchronization  as  defined  in  paragraph  3. 1.4. 1.9. 

3. 1 . 1 .4  Networic  Logger  Interface.  The  ARWA  SS  shall  provide,  as  defined 
in  Appendix  C,  the  capability  for  interface  into  the  Data  Logger  function  of  the  Battlefield 
Distributed  Simulation-Development  (BDS-D)  network. 

3. 1 .2  Threat.  This  paragraph  is  required  by  MIL-STD-490  and  does  not  apply  to  non¬ 
weapon  systems. 

3. 1 .3  System  Modes  gnd  States.  The  SSM  and  each  logical  segment  in  the  SSM  shall 
operate  within  the  set  of  system  level  modes  and  states  defined  in  the  following  paragnq)hs. 
liie  SSM  and  each  segment  within  the  SSM  shall  be  capable  of  transitioning  among  the 
modes  as  defined  in  tl»  described  in  the  mode  transition  diagram  (Figure  3.1.3-1).  The 
system  mode  and  state  interface  definition  shall  be  as  defined  in  the  ARWA  simulation 
device  Interface  Design  Documents.  The  command  to  transition  between  modes  shall 
originate  in  the  Session  Manager  Subsystem.  The  command  shall  be  passed  for 
implementation  to  the  Control  segment  (via  the  &iviroiunent  segment  DIS  interface)  located 
within  the  Simulator  System  module,  for  implementation  within  the  affected  ARWA 
Device. 


Figure  3. 1.3-1  ARWA  Simulate  Subsystem  Mode  Transition  Diagram 


3. 1.3.1  Segment  Mode.  Each  SSM  segment  shall  initialize,  from  a  power  off  state, 
in  the  segment  mode.  When  a  segment  is  operating  in  the  se^ent  mode,  it  shall  not  cause 
a  break  or  discontinuity  in  the  vir^  network  (VT^T).  During  segment  mode  operations. 
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the  segment  shall  be  in  an  undefined  state  with  respect  to  the  system  (i.e.  it  shall  operate  as 
a  stand-alone  entity).  It  shall  not  communicate  with  the  VNET  until  the  segment  has 
transitioned  to  system  mo^  via  an  internal  segment  request  The  system  mode  transition 
request  shall  occur  after  the  segment  shall  perform  ta^  which  are  internal  to  the  local 
segment  hardware  or  software  diagnostics  or  preparation  for  system  mode  operations. 
Prior  to  transition  to  system  mode,  a  segment  shall  perform  the  following  tasks 
automatically: 

a.  Start-iq).  During  the  start-up  sequence,  segment  power  shall  be  applied. 
Power  shall  be  applied  to  all  computational  system  hardware  compments 
(e.g.  flight  deck,  back-door  interfaces,  linkage,  etc.),  and  peripherals, 
required  for  system  mode  operation. 

b.  Load  System  Software.  Following  completion  of  the  start-up  sequence,  the 
software  required  for  system  level  operations,  shall  be  loaded  into  the 
segment's  computational  system. 

c.  Checkout  Following  segment  initialization  and  software  loading,  the 
segment  shall  perform  a  series  of  checks  to  ensure  its  integrity  to  support 
system  modb  operations.  These  checks  shall  be  performed  priw  to  system 
mode  transition.  A  segment  shall  not  transition  to  syston  mode  with  known 
hardware  or  software  faults  which  could  impair  system  operation. 

3. 1.3.2  System  Mode.  In  the  system  mode,  each  segment  shall  have  transitioned 
from  segment  mode  and  is  considered  to  be  in  a  ready  state  with  respect  to  the  system. 
During  system  mode  operations,  each  segment  shall  be  fully  connected  to  the  VNET.  The 
segment  shall  be  in  a  wait  state  and  shall  only  perform  mode  transitions.  Each  segment 
shall  collect  data  from  the  VNET,  and  respond  to  mode  transition  commands  from  the 
Control  segment  The  System  Modes  shall  consist  of: 

a.  Simulation 

b .  Remote  Controlled  Diagnostic 

c.  Shutdown 

3. 1.3.3  Simulation  Mode.  This  mode  shall  cause  the  SSM  to  execute  real  time 
simulation  software  in  support  of  real  time  simulation  activities.  All  segments  shall  be  in 
system  mode  prior  to  entering  training  mode.  The  state  transition  diagram  for  the 
simulation  mode  states  shall  be  as  shown  in  Figure  3.1. 3.3-1.  The  command  to  transition 
between  states  shall  originate  in  the  Session  Manager  Subsystem.  The  command  shall  be 
passed  for  implementation  to  the  Control  segment  (via  the  Environment  segment  DIS 
interface)  located  within  the  Simulator  System  Module,  for  implementation  within  the 
affected  ARWA  device.  The  Simulation  mode  shall  consist  of  the  following  four  states: 

a.  Initialization 

b.  Alignment 

c.  Total  Freeze 

d.  Run 

Each  state  shall  be  as  described  in  the  following  paragraphs. 

3. 1 .3.3. 1  Initialization  State.  This  state  shall  cause  the  real  time  simulation  software 

to  initialize  with  a  predefined  set  of  data.  Default  initial  conditions  shall  be  stored  local  to 
the  segment  Additional  initialization  data  or  changes  to  the  default  initialization  data  shall 
be  sent  to  each  segment  via  the  VNET  if  required  for  a  simulation  exercise.  Changes  to 
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initialiatioa  data  shall  be  limited  to  the  adaptability  panmetets  identified  in  Appei^  B. 
Each  segment  shall  transition  from  this  state  to  the  alignment  state  once  initializatitm  has 
cornfAe^  and  a  request  has  been  received  from  the  Control  s^ment 


Figure  3.1. 3.3-1  ARWA  Simulator  Subsystem  State  Transition  Diagram 


3.1.3.3.2  Alipiment  Stote.  This  state  shall  cause  the  SSM  segments  to  enter  a  steady 
state  condition  utilizing  the  initial  conditions  data.  All  instruments  and  onboard  computer 
systems  shall  be  set/reset  to  known  conditions/states.  Each  segment  shaU  indicate  to  the 
Control  segment  when  its  alignment  is  complete.  When  all  segments  have  indicated 
alignment  complete,  the  Control  segment  shall  issue  a  state  transition  into  the  Total  Freeze 
State.  Each  mt^ule  shtdl  respond  to  the  Total  Freeze  State  transition  command. 


3. 1 .3.3.3  Total  Freeze  State.  This  state  shall  cause  all  system  simulations  to  cease 

execution.  Each  module  shall  "freeze"  the  simulation  by  discontinuing  updates  of 
simulation  variables.  In  d»  Total  Beeze  State,  all  segmmits  sl^  maintain  communicaticHi 
with  the  VNCT.  TransititHi  to  initialization,  alignment,  or  run  state  shall  be  permitted  upcm 
receipt  of  a  command  frcm  the  Ctmtrol  segment 


3.1.3.3.4  Run  State.  This  state  shall  cause  all  segments  to  execute  real  time 
simulation  software.  The  system  shall  be  ctq)able  of  transitioning  from  this  state  to  the 
Total  Beeze  state. 


3. 1.3.4  Remote  Controlled  Diagnostic  Mode.  Each  module  ^all  provide  a  self-test 
function  invokable  from  outside  the  module.  Each  module  shall  provide  two  self-test 
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features;  an  "echo-back"  feature  and  a  equipment  test  feature.  For  the  echo  back  feature, 
the  module  shall  be  able  to  receive  any  ARWA  global  bus  message  expected  for  the 
particular  module,  and  echo  its  contents  back  to  the  ARWA  global  bus.  For  the  equipment 
test  feature,  each  module  shall  poll  every  piece  of  equipment  located  within  the  module  and 
report  back  a  pass/fail  status  to  the  ARWA  global  bus. 

3. 1 .3.5  Shut  Down  Mode.  The  Control  segment  shall  command  each  segment  to 
transition  from  system  mode  to  shutdown  mode.  Each  segment  shall  accomplish  an 
orderly  shutdo^  of  all  system  level  processes.  Shutdown  shall  not  require  power  down, 
unless  the  VNET  can  be  maintained  with  segment  power  removed.  Each  segment  shall 
send  a  final  shutdown  active  mode  selection  reply  to  &e  Control  segment  immediately  prior 
to  discontinuing  communication  with  the  VI^T.  Upon  completion  of  shutdown  mode 
activities,  the  segmrat  shall  automatically  transition  to  the  segment  mode. 

3.1.4  System  Functions.  The  ARWA  SS  shall  adhere  to  the  following  system  level 
requirements: 


a.  Interoperability  with  other  simulators  in  the  network  shall  be  defined  by  the 
Distributed  Interactive  Simulation  (DIS)  protocols.  Version  2.0,  Third 
Draft 

b.  Simulation  of  aircraft  malfunctions  shall  be  based  solely  as  a  direct 
consequence  of  simulated  battle  damage.  There  shall  be  no  discretely 
selectable  stochastic  or  operator  insertable  malfunctions.  The  approach  to 
simulated  battle  damage/malfunctions  shall  be  as  defined  in  Appendix  A  of 
this  specificadort 

c.  The  SSM  shall  provide  the  simulation  adaptability  parameters  listed  in 
Appendix  B  to  be  changed  without  reprogramming.  Pre-mission  access  to 
these  parameters  shall  be  provided  to  allow  rapid  modification  to  support 
simulator  experiments.  Parameter  modification  shall  not  require 
recompilation  of  source  software  to  impl^ent  changes. 

d.  Simulation  capabilities  to  move,  shoot,  communicate,  rearm,  and  be 
resupplied  in  a  simulated  war  fighting  environment  shall  be  provided. 
Simulation  for  aspects  involving  mission  pre-flight,  start-up,  run-up, 
shutdown,  and  post-flight  procedures  is  not  required. 

e.  Simulated  ground  operations  shall  include  tactical  resupply  and  rearming. 
Ground  operations  do  not  include  engine  start,  engine  run-up,  engine  and 
aircraft  shutdown.  Taxi  capabilities  are  not  requii^. 

f .  Simulation  of  the  transition  from  the  ground  environment  to  flight  and  from 
flight  to  the  ground  envirorunent,  including  aerodynamic  ground  effects 
shall  be  provided. 

g.  The  ARWA  devices  shall  provide  the  capability  to  simulate  low  level, 
contour,  nap  of  the  earth,  masking  and  urunasldng,  and  hovering  fli^t 
to  the  level  of  fidelity  defined  in  the  AH-64D  and  RAH-66  Kit 
System/Segment  Specifications. 

h.  Simulation  to  support  equipment  pre-flight,  post-flight,  checkout,  and 
adjustment/calibration  procures  is  not  required. 
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i.  Simulation  of  equipment  (^rational  characteristics  such  as  power/circuit 
breaker  status,  warm-up  times,  overheat/reset  conditions  built-in-test, 
delays,  and  failures  induced  by  incorrect  crew  member  procedures  is  not 
required.  Equipment  power-on  status  shall  be  defined  during  pre-mission 
initialization. 

j .  Simulation  of  equipment  interference  effects  caused  by  other  onboard 
aircraft  systems  is  not  required. 

An  ARWA  device  shall  be  composed  of  three  modules  as  delineated  herein. 

3. 1 .4. 1  System  Simulation  Module.  The  System  Simulation  module  is  comprised 
of  ten  segments:  flight  controls,  flight  dynamics,  propulsion,  navigation/communication, 
weapons,  sensor  control,  aircraft  survivability  equipment,  physical  cues, 
instructor/operator  station  and  tactical  and  natural  envinuiment.  Physical  separation  of  the 
segments  is  not  required.  The  control  segment  and  tactical  and  natural  environment 
segments  are  common  segments  among  the  two  airframe  conffgurations.  These  common 
segments  are  defined  in  the  following  paragraphs. 

3. 1 .4. 1 . 1  Control  Segment  The  control  segment  shall  provide  the  central  point  of 
control  for  the  ARWA  Device.  The  control  segment  shall  provide  the  capabilities  for 
simulator  control  and  the  system  parameter  modification  function.  The  control  segment 
shall  not  provide  any  instructional  features. 

3. 1 .4. 1 . 1 . 1  Simulator  Control.  The  capability  to  control  the  high  level  activities  which 
are  common  to  all  segments  such  as;  modes  and  states,  segment  synchronization  shall  be 
provided  The  control  segment  shall  also  provide  the  synchronization  and  timing  signal 
used  by  all  other  segments.  The  control  segment  shall  Unction  as  the  central  controlling 
mechanism  for  the  /^WA  Device. 

The  simulator  control  function  shall  provide  the  capability  to  control  and  monitor  the 
following  high  level  control  activities  for  the  ARWA  Device: 

a.  Simulator  mode  and  state  control  and  monitoring  as  deffned  in  paragraph 
3.1.3  of  this  specification. 

b.  Simulation  timing  and  synchronization  shall  be  initiated  by  the  Control 
segment  The  lOS  module  shall  provide  a  synchronization  message  at  the 
beginning  of  each  frame.  Synchronization  and  timing  shall  be  accomplished 
as  defin^  in  paragraph  3. 1.5. 1.4. 

c.  The  Control  segment  shall  receive  control  requests  from  the  Session 
Manager  subsystem  and  allocate  these  reqitests  to  Ae  appropriate  simulation 
segments  to  effect  the  desired  response. 

3. 1 .4.1. 1 .2  System  Parameter  Modification.  The  Control  segment  shall  provide  the 
capabili^  to  modify  system  parameters  so  that  the  device  performance  can  be  changed.  See 
.^lendix  B  for  a  detahed  listing  of  data  requiimrats. 

3. 1.4. 1.2  Bivironment  Segment.  The  Environment  segment  shall  provide  simulation 
of  the  environment  external  to  the  ownship.  The  ARWA  (tevice  shall  operate  only  in  the 
multi-simulator  mode,  therefore  the  Environment  segment  shall  provide  a  simulated 
environment  consistent  with  the  networked  DIS  environment  This  environment  shall 
appear  "seamless"  to  the  remainder  of  the  ARWA  devices.  In  this  context  "seamless" 
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means  thm  the  other  segments  in  the  ARWA  device  cannot  distinguish  between  the  internal 
Environment  simulation  and  the  external  updated  information.  The  fidelity  of  this 
simulation  varies  for  each  function  as  detailed  t^low. 

3. 1.4. 1.2.1  Network  Interface.  The  network  interface  shall  provide  for  information 
updates  conforming  to  the  Distributed  Interactive  Simulation  (DIS)  standard  (Version  2.0, 
third  draft).  The  Environment  segment  shall  provide  this  information  to  the  ongoing 
simulation  of  the  ownship  environment  as  appropriate.  The  Environment  segment  shall 
perform  all  necessary  conversions  to  conform  to  ARWA  internal  data  formats  and  units. 

3. 1 .4. 1 .2.2  Atmosphere.  The  Environment  segment  shall  provide  for  simulation  of  a 
medium  fidelity  atmosphere.  It  shall  simulate  air  mass,  global  winds,  and  turbulence.  It 
shall  provide  global  definitions  of  temperature  and  pressure.  It  shall  not  simulate  local  area 
weather  effects  such  as  local  thunderstorms,  micro-bursts,  etc.  It  shall  not  simulate 
precipitation  effects  such  as  rain,  snow,  sleet,  etc. 

3. 1.4. 1.2.3  External  Entities.  The  Environment  segment  shall  simulate  the  position  and 
attitude  of  other  vehicles  between  updates  from  the  DIS  environment.  Upon  receiving  such 
updates,  the  Environment  segment  shall  "seamlessly”  inject  the  new  data  into  the  vehicle 
simulation. 

3. 1 .4. 1 .2.4  Qvmship  W^pon  Dainage.  The  Environment  segment  shall  provide  to  the 
DIS  environment  information  regarding  ownship  weapon  path,  detonation  and  ordinance. 
This  information  shall  be  defined  in  the  Weapon  segment  and  shall  be  passed  to  the  external 
simulation  through  the  Network  Interface  function  of  the  Envirorunent  segment 

3. 1 .4. 1 .2.5  Threat  Weapon  Dynamics.  The  Environment  segment  shall  simulate  the 
flight  of  threat  weapons  between  updates  from  the  DIS  environment.  This  simulation  is 
limited  as  defined  in  paragraph  3. 1.4. 1.2.3  above. 

3.1.4. 1 .2.6  Threat  Platform  Dynamics.  The  Environment  segment  shall  simulate  the 
flight  of  threat  platforms  between  updates  from  the  DIS  envirorunent.  This  simulation  is 
limited  as  defined  in  paragraph  3. 1.4. 1.2.3  above. 

3- 1.4.2  Flight  Station  Module.  The  Flight  Station  module  shall  provide  the 
simulation  of  the  electrical,  hydraulic,  and  fuel  systems  and  the  crew  station  interfacing 
systems  for  each  of  the  application  aircraft.  Pneumatic  system  simulation  is  not  required. 
The  Flight  Station  module  shall  include  the  crew  compartment  enclosure,  controls  and 
indicators.  The  module  level  physical  and  performance  characteristics  requirements  are 
defined  in  Volume  n  of  this  specification. 

3. 1.4.3  Visual  Module.  The  Visual  module  shall  provide  the  visual  and  sensor 
cueing  requirements  for  each  of  the  aircraft  defined  in  paragraph  3.1  of  this  specification. 
This  shall  include  visual  and  sensor  image  generation,  moving  models,  lighting, 
environmental  scene  generation,  crew  station  interfacing  and  out-the-window  display 
system.  The  physical  and  performance  characteristics  requirements  are  contained  in 
Volume  IQ  of  this  specification. 

3. 1 .4.4  Support  Systems.  The  following-paragraphs  identify  the  requirements  for 
the  support  systems  which  shall  be  part  of  the  ARWA  SS.  The  support  systems  shall 
provide  the  system  management,  maintenance,  and  control  for  the  ARWA  SS. 

3. 1.4.4. 1  Simulation  Manager.  The  simulation  manager  shall  provide  centralized 
control  of  the  simulation  exercise.  The  simulation  manager  shall  connect  to  the  ARWA  SS 
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Local  Area  Netwoik  (LAN)  and  shall  be  responsible  for  controlling  the  exercise  for  devices 
connected  to  the  ARWA  SS  LAN.  Functions  of  tie  simulation  manager  shall  include  the 
following: 

a.  Mo(te  and  State  Control.  The  simulation  manager  shall  be  capable  of 
controlling  the  mode  and  state  of  each  ARWA  cormected  to  the  BDS-D 
network.  The  modes  and  states  shall  be  as  defined  in  paragraph  3.1.3. 

b.  Data  Logger.  The  simulation  manager  shall  provide  a  data  collection 
fimction  for  BDS-D  network  traffic.  The  data  collection  shall  be  possible  in 
three  formats;  1)  collect  all  BDS-D  data;  2)  collect  selected  BDS-D  messages 
and  3)  record  instances  of  selected  messages  with  data  of  a  specified  value. 
The  data  logger  shall  be  capable  of  collecting  and  storing  data  for  future 
analysis. 

c.  Late  Player  Introduction.  The  simulation  manager  shall  provide  the 
capability  to  introduce  players  into  an  exercise  which  is  running.  Late 
player  introduction  shall  be  accomplished  without  degradation  to  the 
existing  exercise. 

d.  System/Exercise  Startup,  Maintenance  and  Control.  The  simulation 
manager  shall  provide  the  capability  to  load  each  ARWA  with  the 
appropriate  software  required  to  execute  the  planned  exercise  and 
stail/restart  the  device.  The  simulation  manager  shall  also  be  capable  of 
providing  refuel/resupply  to  the  devices  in  the  exercise. 

e.  Parameter  Editing.  The  simulation  manager  shall  provide  the  capability  to 
edit  key  simulation  parameters  for  experimental  purposes.  The  parameters 
which  shall  be  editable  shall  be  as  sp^ified  in  Appendix  B.  The  following 
rules/requirements  shall  apply  to  the  parameter  editing  function: 

(1)  Each  segment's  editable  parameters  shall  be  defined  by  an 
initialization  file.  To  change  a  parameter  set,  a  new  initialization 
shall  be  required.  A  default  value  shall  be  defined  for  each  editable 
parameter. 

(2)  Development,  editing  and  storage  of  the  initialization  files  shall  be  an 
off-line,  non-real-time  function. 

(3)  Introduction  of  new  parameter  values  (a  new  file)  shall  not  cause  a 
re-compilation  or  re-Unking  of  any  task. 

(4)  All  initialization  shall  be  initiated  by  the  simulation  manager  station. 

(5)  The  segments  shall  use  the  initialization  file  during  an  aligiunent  or 
reposition  process. 

(6)  Parameters  shall  not  change  in  real-time  but  shall  be  constants  (data) 
for  the  affected  segment  A  new  initialization  process  shall  occur  in 
order  to  modify  parameters. 

3.1. 4.4.2  Management  Command  and  Control.  A  Management  Command  and 

Control  (MCC)  station  shall  be  provided  as  follows: 
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a.  Requirements/Functionality.  The  Aviation  MCC  has  been  described  in  the 
AERNET  Functional  specification  -  M(X  Work  Station  Screens  (June  91). 
This  document  describes  the  functions  to  be  performed  by  die  MCC 
workstation  for  rotary  wing  operations  and  shall  be  used  as  a  guide  in  the 
design  process. 

b.  Aviation  SIMNET  Command  and  Control  (SCC).  Extend  the  current  armw 
MCC  to  incorporate  aviation  organization  and  parameters  into  an  AIRNET 
MCC.  The  only  console  inducted  in  this  effort  is  the  SCC.  This  effort 
includes  replacing  the  current  AppleTalk  bridge  to  enhance  poformance. 

c.  Aviation  Admin/Log  Console.  Extend  the  current  armor  Admin/Log 
Console  to  be  an  aviation  Admin/Log  Console.  It  will  include  forward  area 
rearm/refuel  point  (FARRP)  and  support  any  special  aviation  ammunition, 
fuel,  and  supplies. 

d.  Aviation  Maintenance.  Extend  the  Armor  Maintenance  Console  to  be  an 
Aviation  Maintenance  (AVUM)  console.  It  will  support  rotary  wing  aircraft 
specific  repairs. 

e.  Aviation  Fire  Support.  Will  integrate  the  current  Fire  Support  Element 
(FSE),  Close  Air  Support  (CAS),  and  place  consoles  with  the  aviation 
MCC.  The  FSEs  will  reflect  aviation  organizational  structure. 

f.  Battalion  Air  Console.  Implement  aviation  support  features  such  as 
carrying  vehicles  by  a  rotary  wing  aircraft  and  will  support  transporting 
sling  loads  of  fuel  and  ammunition  around  the  battlefield. 

3. 1 .4.4.3  System  Maintenance.  The  system  maintenance  function  of  the  ARWA  SS 
shall  provide  a  non-real-dme  capability  to  maintain  the  ARWA  SS  and  accomplish  die  tasks 
required  to  maintain  the  System  with  respect  to  software  maintenance,  configuration 
management  of  hardware  and  software  and  software  develoimient. 

3.1. 4.4.3. 1  Software  Maintenance.  The  capability  to  perform  software  maintenance  for 
the  entire  ARWA  SS  shall  be  provided.  All  hardware  and  software  shall  be  provided  for 
the  software  maintenance  function.  The  software  maintenance  function  shall  provide  the 
following  capability: 

(a)  Development,  modiftcation,  and  configuration  of  all  software 
associated  with  the  ARWA  SS.  Commercial  off-the-shelf  software 
shall  be  excluded  from  this  requirement 

(b)  Creation  and  maintenance  of  test  and  experiment  software  including 
parameter  editing  files. 

(c)  Configuration  management  of  hardware  configuration  of  each 
ARWA  for  security  purposes. 

(d)  Library  of  all  system  information  such  as  security,  configuration 
management  magnetic  media  documentation,  and  results  of  tests 
and  experiments. 
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(e)  Maintenance  and  storage  of  all  databases  excluding  the  visual 
database  which  will  be  provided  by  the  Database  Maintenance 
function. 

3.1.4.4.3.2  Database  Maintenance.  The  database  maintenance  fimction  shall  provide  the 
ci^ability  to  modify  and  maintain  the  visual  databases  for  all  of  the  ARWAs. 

3.1.5  System  Functional  (Intermodule^  Relationships.  The  ARWA  SS  design  shall  be 
implemented  in  a  manner  consistent  with  the  rules  of  the  Modular  Simulator  System  as 
de^ed  herein.  The  following  paragraphs  describe  the  intermodule  requirements  for  an 
ARWA  device. 

3. 1.5.1  Interfunctional  and  Intermodule  Rules.  The  foUowing  paragraphs  identify 
the  interfimctional  and  intermodule  rules  for  the  ARWA  device. 

3. 1.5. 1.1  Global  Bus  Information  Rules.  Digital  video  data  and/or  grt^cal  imaging 
data  (streams  of  lines  and  symbols,  streams  of  range,  elevation  and  azimuUi  angles)  shall 
not  be  transmitted  via  the  ARWA  global  bus.  Unprocessed  data  shall  not  be  accessed 
across  the  ARWA  global  bus  during  real-time  operation.  The  ARWA  global  bus  interfEK^e 
shall  be  as  described  in  paragraph  3.1.7  and  Appendix  A  of  the  ARWA  SSM  Interface 
design  Document  (IDD). 

3. 1 .5. 1 .2  Crew  Station  Interfacing  Rules.  The  crew  station  hardware  interface  shall 
be  accomplished  as  described  in  this  specification.  The  following  paragraphs  ickntify  the 
crew  station  hardware  interfacing  rules. 

3. 1 .5. 1 .2. 1  Raw  Data  Controls  and  Displays.  Crew  station  control  and  display  of  raw 
data,  or  derivations  thereof,  shall  be  accomplished  through  the  Flight  Station  module.  All 
modules  shall  send  control  and  display  data  to  the  Flight  Station  module  via  the  ARWA 
global  bus.  Such  data  shall  be  in  the  form  of  engineering  units,  as  given  in  Appendix  A  of 
the  ARWA  SSM  IDD.  The  Flight  Station  modtde  shall  be  responsible  for  processing  such 
data  as  required  to  drive  the  control  or  display  to  the  respective  position  or  indication. 
Likewise,  control  inputs  shall  be  processed  and  sent  to  the  appropriate  modules  using  the 
same  meAods. 

3. 1 .5. 1.2.2  Tightly  Coupled  Controls  gnd  Displays.  Controls  and  displays  which  are 
tightly  coupled  to  functions  in  a  particular  module  shall  interface  via  a  dedicated  interface  to 
the  associated  module,  and  not  via  the  ARWA  global  bus  to  the  Flight  Station  module. 
Tightly  coupled  controls  and  displays  are  those  for  which  control  and  display  are  both 
dedicated  and  complex  and  the  performance  of  the  control  and  display  system  is  highly 
integrated  with  the  performance  of  the  related  simulation  in  the  associated  modules.  Ti^dy 
coupled  also  refers  to  those  cases  where  transport  delay  must  be  minimized.  The  tightly 
coupled  controls  and  displays  for  the  ARWA  shall  be  as  follows: 

a.  Primary  flight  controls.  Cyclic,  collective,  and  directional  pedals,  and  3 
axis  cyclic  as  applicable. 

b.  Video  displays.  Helmet  mounted  displays  and  out-the-window  displays. 

c.  Video  Mixing.  Video  data  from  the  Moving  Map  fimction  and  the  Visual 
Image  Generation  function  shall  be  interfaci^  dii^tly  to  the  Flight  Station 
Symbol  Generator  function  for  the  cockpit  multi-function  displays. 
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3. 1 .5. 1 .3  Coordinate  System.  The  coordinate  system  utilized  on  the  ARWA  global 
bus  shall  be  the  earth  axis  coordinate  system  which  is  defined  by  latitude,  longitude  and 
height  above  mean  sea  level.  Individual  modules  shall  perform  transformations  as 
necessary  to  conform  to  the  earth  axis  coordinate  system. 

3.1.5. 1.4  Synchronization  and  Timing.  All  system  level  timing  and  synchronization 
shall  be  initiated  by  the  lOS  segment.  The  lOS  segment  shall  provide  a  high  priority 
broadcast  synchronization  message  (a  "clock  tick"  message)  at  the  ^ginning  of  each  frame. 
The  frequency  of  the  synchronization  message  shall  be  as  deHned  in  the  subparagraphs 
below.  The  format  and  definition  of  the  synchronization  message  shall  be  as  defined  in 
Appendix  A  of  the  ARWA  SSM  IDD.  Each  module  shall  commence  execution  of  the 
appropriate  software  for  the  corresponding  frame  upon  receipt  of  the  synchronization 
message.  The  synchronization  message  shall  be  available  to  all  modules  when  in  the 
system  mode,  remote  controlled  diagnostic  mode,  simulation  mode,  and  shutdown  mode. 
Intra-module  synchronization  methodologies  (internal  to  each  module)  shall  not  be 
constrained  by  ^is  specification  to  the  extent  that  such  methodologies  meet  or  exceed  the 
requirements  specified  herein. 

AU  cues  provided  by  the  Physical  Cues  and  Flight  Controls  segments,  Visual  module  and 
Flight  Station  module  shall  be  properly  synchronized  with  all  other  ARWA  modules  to  the 
extent  that  there  shall  be  no  noticeable  errors  in  time,  position,  velocity  or  acceleration. 
Cue  correlation  transport  delay  (delay  between  any  synchronized  cue)  shall  be  minimized, 
including  the  inherent  delay  of  the  installed  visual  system.  The  System  shall  respond  to 
abrupt  pitch,  roll  and  yaw  inputs  within  the  specified  time,  but  not  before  the  time  when  the 
actu^  application  aircraft  would  respond  under  the  same  conditions. 

The  following  timing  requirements  shall  apply  to  all  modules  in  the  ARWA: 

a.  The  base  rate  and  highest  iteration  rate  for  the  ARWA  shall  be  60  Hz.  This 
is  the  rate  of  the  synchronization  message  on  the  global  bus,  and  the  frame 
rate.  This  rate  does  not  apply  directly  to  module  internal  processing,  as 
long  as  input/output  is  provided  to  the  ARWA  global  bus  at  Ae  appropriate 
rate. 

b.  Distributed  message  transmission  within  a  frame  via  the  global  bus  shall  be 
mandatory.  This  means  when  a  module  completes  the  computations  that 
would  allow  a  message  to  be  transmitted,  the  module  shall  send  that 
message. 

c.  All  message  transmissions  for  a  module  in  each  frame  shall  be  initiated 
within  nine  (9)  milliseconds  from  the  start  of  each  frame.  This  requirement 
is  not  applicable  to  the  synchronization  message,  which  always  starts  each 
frame. 

d .  The  loading  or  balancing  of  specific  module  processing  among  the  available 
simulation  frames  within  a  cycle  (a  cycle  being  the  total  number  of  frames  in 
one  second)  shall  be  mandatory.  All  modules  shall  be  designed  to  allow  for 
additional  fine  tuning  adjustments  to  the  specified  frame  assignments  during 
system  integration,  so  as  to  more  evenly  distribute  global  bus  traffic 
throughout  the  simulation  cycle. 

3. 1.5. 1.5  Common  Processing  Simulation  Functions.  Each  particular  simulation 
function  shall  be  assigned  to  one  and  only  one  module.  Transitions  or  hand-offs  of 
simulation  functions  shall  not  be  allowed  in  real-time. 
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3. 1.5. 1.6  Common  Processing  Service  Functions.  The  Inter-visibility  function  shall 
be  assigned  to  the  TNE  segment,  and  that  assignment  shall  not  be  passed  to  another  module 
in  real-time.  A  module  may  internally  elect  to  provide  itself  the  service  function  in  lieu  of 
the  system  service  function  for  its  own  internal  purposes.  This  shall  be  allowed  as  long  as 
the  fidelity  of  system  operation  is  not  deteriorated. 

3. 1 .5. 1 .7  Simulator  Initialization.  Simulation  initialization  shall  be  implemented  as 
described  in  paragraph  3. 1.3.5. 1  of  this  specification.  Crew  station  setup,  loading  and  any 
other  ancillary  configuration  changes  shall  be  performed  prior  to  simulator  initialization. 

3.1.5. 1.8  Partitioning.  The  ARWA  shall  be  partitioned  into  the  Flight  Station,  Visual 
and  Simulation  System  modules.  The  module  functions  associated  wiA  this  partitioning 
shall  be  as  identified  in  Volumes  I  through  V  of  this  specification. 

3. 1 .5. 1 .9  Diagnostic  and  Performance  Testing.  All  ARWA  level  diagnostics  and 
remote  controlled  diagnostics  shall  be  initiated  by  messages  from  the  lOS  segment  as 
defined  in  Appendix  A  of  the  ARWA  SSM IDD.  Individual  module  local  diagnostics  shall 
be  initiated  by  the  individual  module.  The  results  of  diagnostics  and  performance  testing 
shall  be  recorded  locally  by  each  module  and  stored  for  future  retrieved  and  analysis.  The 
ARWA  global  bus  shall  be  capable  of  use  in  a  non  real-time  environment  for  file  transfer 
via  a  network  file  system. 

3.1.5.1.10  Natural  Environment.  The  characteristics  and  phenomena  of  the  natural 
environment  that  are  simulated  shall  include  atmospheric  pressure,  wind,  temperature, 
visibility,  time  of  day,  sun  angle,  thunderstorms,  lightning,  rain,  hail,  snow,  ice,  wind 
shears  and  turbulence.  The  tactical  and  natural  environment  (TNE)  segment  shall  provide 
the  natural  environment  modeling  for  the  application  aircraft.  The  environment  shall  be 
defined  from  initial  conditions  prior  to  the  exercise  and  shall  not  be  alterable  during  the 
execution  of  an  exercise. 

3..  1 .5.2  Malfunctions.  The  malfunctions  defined  in  Appendix  A  of  this  specification 

shall  be  fully  implemented  by  the  specified  segment  to  the  extent  defined  in  Appendix  A. 
Malfunctions  shall  be  limited  to  those  that  are  a  direct  consequence  of  simulated  battle 
damage  and  shall  not  be  insertable  by  any  operator.  All  malfunctions  shall  be  initiated  by 
the  TPfe  network  interface  function  based  on  weapon  messages  from  the  BDS-D  networic. 

3.1.6  Configuration  Allocation.  Each  module  in  the  ARWA  Simulator  shall  support  the 
interconnections  and  interfaces  shown  in  the  System  interconnect  diagram  (Figure  1.3-2) 

3.1.7  Communication  Architecture  Requirements.  The  Bus  Interface  Unit  (BIU)  shall 
provide  the  physical  and  data  interface  between  the  physical  media  and  the  particular 
module's  application  layer.  The  BIU  shall  utilize  the  Xpress  Transfer  Protocol  (XTP)  as 
defined  by  Protocol  Engines  Inc.  (PEI)  specification  89-103  Revision  3.5  or  an  equivalent 
protocol  as  the  transfer  layer.  The  Fiber  Distributed  Data  Interface  (FDDI)  shall  be  used  as 
the  physical  media  as  defined  by  the  American  National  Standards  Institute  (ANSI)  x3.166- 
1989,  FDDI  -  Physical  Layer  Medium  Dependent  specification  for  a  single  loop  system 
(reference  paragraph  3.1.7.10.2,  Communication  Media). 

The  data  interfaces  shall  include  the  constructs  necessary  to  remove  messages  from  the 
global  bus  addressed  to  a  particular  application  segment;  to  strip  from  the  message  the 
header  and  trailer  data  not  needed  by  the  application  segment;  to  reformat  the  data  to  a  form 
compatible  with  the  module  computational  system;  and  to  reverse  these  processes  for 
messages  transmitted  by  the  module,  including  multiple  addressee  messages.  The  BIU 
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shall  insure  that  the  interface  is  reliable  and  includes  error  and  exception  handling.  All 
message  data  shall  be  formatted  as  specified  in  Appendix  A  of  the  ARWA  SSM  Q)D. 

3. 1.7.1  Bus  Interface  Unit  General  Requirements.  The  BIU  shall  be  comprised  of 
four  major  divisions;  application  services  layer,  session  layer,  transfer  layer  and  physical 
media  layer.  The  application  layer  shall  contain  one  or  more  segments  which  comprise  the 
simulation  math  models  for  a  module.  The  application  segments  shall  communicate  with 
other  application  segments  through  the  BIU  via  a  predefined  set  of  application  services. 
The  appUcation  segments  shall  be  separate  from  each  other  and  the  BIU,  but  shall  interface 
to  the  BIU  through  a  unique  and  distinct  application  layer  to  session  layer  interface  referred 
to  as  the  application  services.  The  logical  interface  definitions  for  the  data  being  transmitted 
and  received  by  the  module  application  layers  shall  be  as  deHned  in  Appendix  A  of  the 
ARWA  SSM  IDD.  The  session  layer  shall  provide  the  communication  link  to  and  from  the 
transfer  layer  for  the  application  layer.  A  module  shall  be  comprised  of  one  BIU  and  one 
application  layer.  An  application  layer  shall  contain  one  or  more  segments. 

The  interface  between  a  segment  and  the  session  layer  shall  be  defined  as  the  application 
services.  The  segment  shaB  not  access  the  ARWA  global  bus  or  another  segment  within 
the  same  module  except  through  the  application  services  for  that  segment. 

3. 1 .7.2  Bus  Interface  Unit  Start  Up.  The  BIU  shall,  upon  the  application  of  power, 
perform  a  self  test  to  verify  functionality.  Upon  successful  verification  of  functionality,  the 
BIU  shall  attach  the  module  to  the  global  bus.  If  the  BIU  should  fail  the  test,  it  shall  not 
attach  the  module  to  the  ring  but  shdl  provide  a  visual  indication  of  a  failure.  The  global 
bus  shall  remain  intact  and  functional  and  the  module  shall  continue  to  pass  on  traffic  from 
other  modules.  An  optical  bypass  shall  be  installed  at  each  module  for  Ais  purpose. 

3. 1.7.3  Bus  Interface  Unit  Performance  Monitoring.  The  performance  of  the  BIU 
shall  be  verified  using  an  FDDI  Bus  Analyzer.  Message  delivery  statistics  shall  be 
recorded  to  verify  performance  (i.e.,  message  transmission  time,  message  receipt  time, 
content  errors).  The  BIU  shall  execute  the  session  layer,  transfer  layer,  and  any  necessary 
background  housekeeping  tasks,  such  as  management  of  module  synchronization  and 
communication  with  the  global  bus  hardware.  The  maximum  allowable  latency  for  the  BIU 
shall  be  550  microseconds.  This  is  the  maximum  time  that  a  BIU  can  take  to  receive  a 
message  transmission  from  a  segment,  pack  the  message  and  pass  it  to  the  global  bus.  It  is 
also  the  maximum  time  that  a  BIU  can  take  to  receive  a  package  message,  place  it  in  a 
buffer,  and  notify  the  proper  segment  that  it  is  present. 

3. 1 .7.4  File  Transfer  Protocol.  The  BIU  shall  support  the  non-real-time  transfer  of 
files  between  modules. 

3. 1 .7.5  Identification  Numbers  for  Messages.  Messages  shall  be  transferred  from 
segment  to  segment  and  include  a  unique  identification  number.  The  identification  number 
shall  be  a  32-bit  integer.  Identification  numbers  shall  be  assigned  for  all  messages  that  will 
be  transferred  on  the  global  bus  for  use  in  the  address  field  of  a  transfer  layer  information 
segment.  To  accomplish  diis,  a  routine  shall  be  used  to  autOi'ratically  parse  the  interface 
specification  to  build  a  master  message  package  consisting  of  all  message  names  as  an 
enumeration  type.  This  shall  ensure  the  correct  configuration  of  messages  between 
modules  and  segments  in  the  System.  The  package  shall  reside  within  the  BIU 
computational  system.  A  particular  module's  segment(s)  shall  only  have  visibility  or 
access  to  the  inputs  and  outputs  which  are  specifically  identified  as  applicable  to  the  module 
in  Appendix  A  of  the  ARWA  SSM  IDD.  \^en  the  master  message  package  is  compiled,  a 
unique  4-byte  (32  bit)  integer  shall  be  assigned  by  the  compiler  to  each  message  name. 
This  integer  shall  be  the  identification  number.  The  same  integer  values  shall  be  assigned 
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to  the  enumerated  types,  regardless  of  compiler  implementation,  given  diat  the  same  (Ada) 
package  is  'withed'  by  each  module. 

3. 1.7.6  Data  Representation.  The  following  paragraphs  identify  the  requirements 
for  data  representation  of  information  on  the  physical  layer  which  shall  be  used  in  the 
ARWA. 

3. 1.7.6. 1  Network  Bvte  Order.  The  network  byte  order  shall  be  as  specified  in  MIL- 
STD-1777,  Internet  Protocol  Specification,  Appendix  A.  The  eight  bits  of  each  byte  shall 
be  transmitted  on  the  media  in  the  order  that  would  be  read  in  a  left  to  right  fashion,  going 
from  low  to  high  memory  locations,  where  the  left  most  bit  shall  be  the  Most  Sigtiiftcant 
Bit  (MSB)  and  the  right  most  bit  shall  be  the  Least  Significant  Bit  (LSB). 

Similarly,  bytes  shall  also  be  transmitted  from  left  to  right,  from  high  order  to  low  order. 
Whenever  a  multi-octet  field  represents  a  numerical  quantity,  the  left  most  bit  of  the  whole 
fteld  shall  be  the  most  signiftcant  bit.  When  a  multi-octet  quantity  is  transmitted,  the  most 
significant  octet  shall  be  transmitted  first  This  is  known  in  the  computer  industry  as  Big- 
Endian  format 

The  byte  number  shall  be  the  offset  in  memory  from  the  lowest  byte  or  the  base  byte.  The 
base  byte  shall  be  the  address  used  when  addressing  die  long  woid  or  half  word  as  a  single 
entity.  Therefore,  Byte  3  shidl  be  a  higher  memory  location  address  than  Byte  0. 

3.1. 7.6.2  Basic  Data  Types.  The  following  data  types  shall  be  used  on  the  global  bus: 

a.  short  integer  8  bit  byte 

b .  integer  16  bit  double  byte  or  half  word 

c.  long  integer  32  bit  quad  byte  or  (long)  word 

d .  float  integer  Single  and  double  precision  IEEE 

Floating  Point  (Spw  No.  754-1985) 

Double  and  single  precision  enumerated  types  on  the  rk  work  shall  begin  with  0  for  the 
first  element  of  die  type  declaration. 

3. 1 .7.6.3  Floating  Point  Numbers.  Numbers  that  are  best  expressed  as  floating  point 
numbers  shall  use  the  floating  point  representation  specified  in  paragraph  3.1. 7.6.2. 

3.1.7.6.4  Order  of  Interpretation  of  Complex  Data  Structures.  Data  structures  shall  be 
placed  on  the  communication  media  in  the  order  they  are  declared  in  the  type  definition. 
This  order  shall  be  defmed  as  left-to-right  and  then  top-to-bottom.  Sub-structures  shall 
comply  with  the  same  interpretation. 

For  example: 

Type  data_structure_n  is  record 
Latitude:  Float; 

Longitude:  Float; 


end  record; 
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Type  dat2L.stnicture  is  record 

Altitude:  Float; 

Heading:  Float; 

Portion:  data_stracture_n; 
end  record; 

An  object  of  type  data.structure  would  be  sent  in  the  following  order:  Altitude,  Heading, 
Latitude  and  Longitude. 

3. 1.7.7  Module  Address  Translation  Table.  In  each  module's  BUT  there  shall  be  an 
input/output  address  for  each  message  processed  by  a  particular  application.  This  address 
shall  contain  information  on  the  originating  segment  and  all  destination  segments  as  a  bit¬ 
mapped  address.  These  addresses  shall  be  unique  to  the  BIU  and  the  particular  segment  of 
that  module.  Ihe  segment  that  originates  a  message  and  tire  destinations  of  the  messages 
shall  be  as  defined  in  Appendix  A  of  the  ARWA  SSM IDD.  Each  module  or  segment  BIU 
shall  contain  a  Module  Address  Translation  table,  developed  off-line  that  defines  the 
hardware  address  of  the  source  and  destination  of  every  message  defined  in  Appendix  A  of 
the  ARWA  SSM  IDD. 

3. 1.7.8  Session  Layer.  The  session  layer  of  the  BIU  shall  handle  the 
communication  of  data  from  one  segment  to  another  within  the  same  module  and  betwera  a 
segment  and  the  transfer  layer,  and  from  transfer  layer  to  the  appropriate  segments  in  each 
m^ule.  This  is  derived  from  the  session  layer  of  the  Intemational  Standards  Organization 
for  Open  System  Integration  (ISO/OSI)  model  and  such  parts  of  the  presentation  layer  of 
the  ISO/OSI  model  as  may  be  necessary  to  convert  from  one  data  format  to  another, 
depending  on  the  type  of  computational  system  ruiming  the  segments'  software  within  the 
application  layer.  I^e  BIU  session  layer  software  sht^  run  as  a  task  independent  of  the 
application  layer  with  a  minimal  amount  of  interfacing  to  the  application  layer  (via  the 
application  services). 

3. 1.7.8. 1  Memory  Requirements.  The  amount  of  memory  required  by  the  BIU 
session  layer  shall  be  determined  by  the  amount  of  buffer  space  required  for  message  traffic 
at  a  module.  Since  each  module  has  different  numbers  and  sizes  of  messages,  the  required 
amount  of  buffer  space  can  vary  from  module  to  module.  The  BIU  shall  provide  memo^ 
space  to  handle  the  message  traffic  for  tire  module  with  the  highest  memory  requirements  in 
the  system.  This  shall  allow  for  Interchangeability  among  modules  for  later  system 
debugging  and  checkout.  BIU  memory  shall  also  be  provided  for  the  session  layer 
software,  transfer  layer,  global  bus  board  drivers  and  any  applicable  BIU  support 
programs. 

3.1. 7.8.2  Data  Flow.  As  messages  are  received  from  the  global  bus  and  processed  by 
the  session  layer,  the  segments  within  die  application  layer  shall  notify  the  BIU  of  the 
messages  to  received/sent  The  segments  shall  process  received  messages  as  they 
arrive.  The  segments  shall  establish  the  importance  of  a  given  message.  The  message 
identification  number  shall  be  used  to  interpret  the  message  contents.  Messages  shall  be 
passed  between  a  segment  and  the  session  layer  in  the  appropriate  segment  format  The 
BIU  shall  perform  any  necessary  format  translations.  Each  segment  shall  have  the  ability 
to  request  the  status  of  the  last  operation  in  order  to  make  decisions  on  important  message 
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transfers.  Each  modute's  session  layer  shall  have  access  to  only  to  those  messages  used  by 
that  particular  module. 

Messages  shall  be  passed  between  the  session  layer  and  the  transfer  layer  in  a  format  that  is 
compatible  with  the  transfer  layer  protocol.  A  context  shall  exist  between  nodes  which  are 
required  to  communicate  prior  to  messages  being  transmitted/received  on  the  global  bus. 
Each  segment  shall  establish  the  need  for  the  context  when  the  Input/Output  (I/O) 
infonnation  is  provide  to  the  BIU.  The  status  of  transfers  shall  be  monitored  by  the 
session  layer  and  made  available  to  the  appropriate  segment(s)  upon  request  by  the 
segments). 

3.1.7.8.3  Session  to  Transfer  Laver  Interface.  Any  commands  to/from  the  transfer 
layer  shall  be  in  the  form  of  process  operations  established  by  a  segment  using  the  session 
layer.  The  I/O  operations  shall  be  accomplished  without  the  loss  of  any  data  and  expedited 
as  dictated  by  the  segment.  As  soon  as  data  is  received  by  the  session  layer  from  the 
transfer  layer,  it  shall  be  processed  for  delivery  to  the  appropriate  segments).  A  receive 
operation  shall  be  posted  by  the  session  layer  in  order  to  move  data  from  the  transfer  layer 
to  the  session  layer.  A  receive  operation  shall  be  posted  for  each  expected  message.  A 
send  operation  shall  be  posted  by  the  session  layer  in  order  to  move  data  from  the  session 
layer  to  the  transfer  layer.  When  the  transfer  layer  has  completed,  an  VO  transaction  a 
response  message  shall  be  written  to  the  session  layer.  The  session  layer  shall  continually 
monitor  the  operational  status  of  the  transfer  layer  for  response  messages. 

3. 1.7. 8.4  Session  Layer  to  Application  Laver  Interface.  Communication  between  the 
session  layer  and  segments  in  the  application  layer  shall  be  in  the  form  of  application 
service  calls  made  by  the  segment  Each  service  shall  return  the  status  of  the  operation  that 
was  performed.  The  following  services  shall  be  provided,  as  a  minimum,  to  the  individual 
segments  in  the  form  of  function  or  procedure  calls: 

a.  Define_A_Message_Record_For.  This  service  shall  define  a  message 
record  and  attach  it  to  the  message  buffer  in  the  Session  Layer  for  that 
message.  The  message  record  shall  consist  of  the  following: 

(1)  The  status  of  the  last  operation. 

(2)  The  age  of  the  message. 

(3)  The  message  size  in  bytes. 

(4)  The  message  buffer  address. 

The  Define_A_Message_Record_For  service  shall  be  caUed  once  for  each 
message  sent  or  received  by  a  segment  prior  to  simulation  start  up.  An  error 
condition  shall  exist  if  any  other  service  is  called  for  a  message  which  has 
not  been  defined.  The  parameters  for  this  service  shall  be  as  follows: 

(5)  Message_Name.  This  parameter  shall  be  provided  as  a  string  as 
defined  in  Appendix  A  of  the  ARWA  SSM IDD. 

(6)  Send_Or_Receive_Mode.  This  parameter  shall  define  whether  a 
message  is  an  input  or  an  output  and  the  action,  if  any,  to  be  taken. 
Valid  modes  shall  be  as  follows: 

(a)  Send_And_Retum 
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(b)  SeiKl_.And_WaitJFor_Ackiiowledgenieiit 

(c)  Receive_Most_Recent_Message 

(d)  Receive_And_Intemipt 

(7)  Interrupt  Handler  Address.  This  parameter  shall  (mly  he  used  for 
Reoeive_And_Interrupt  mode. 

h.  Change_Send_Or_Receive_Mode_()f.  This  s^vice  shall  enable  a  segment 
to  change  the  mode  of  a  message  record  that  has  already  been  defin^  for 
that  segment  A  send  message  shall  not  be  changed  to  a  receive  message, 
the  reverse  shall  also  be  true.  The  parameters  for  this  service  shall  be  as 
follows: 

(1)  The  new  SaidjC)r_Receive_Mode. 

(2)  Interrupt  Handler  Address.  This  parameter  is  only  used  for 
Reoeive_And_Interrupt  mode. 

(3)  The  message  record. 

c.  Send.  This  service  shall  send  tl»  given  message,  using  the  current  send 
mode  associated  with  the  message.  An  error  condition  shall  exist  if  the 
message  is  marked  with  one  of  the  receive  modes.  The  parameters  for  this 
service  shall  be  as  follows: 

(1)  The  message  record. 

d.  Receive.  This  service  shall  receive  the  given  message  using  the  current 
receive  mode  associated  with  the  message.  An  error  condition  shall  exist  if 
the  message  is  marked  with  one  of  the  send  modes.  The  parameters  for  this 
service  shall  be  as  follows: 

(1)  The  message  record. 

e.  Status_Of_Node.  This  service  shall  return  the  status  of  the  module's  BIU. 
The  parameters  for  this  service  shall  be  as  follows: 

(1)  The  segment  name  as  specified  in  Appendix  A  of  the  ARWA  SSM IDD. 

f.  Initialize.  This  service  shall  initialize  the  application  layer  sovices  and  BIU 
variables  in  preparation  for  starting  the  BIU's  operation.  This  shall  be 
performed  prior  to  using  any  of  the  other 

g.  Start  BIU.  This  service  shall  enable  the  BIU  for  the  start  of 
communication.  This  service  shall  be  called  after  all 
Define_A_Message_Record_For  calls  and  before  the  first  call  to  send  or 
receive. 

3.1.7. 8.5  Initialization.  Before  the  transmission/reception  of  messages  can  be 

accomplished,  buffer  space  shall  be  allocated  to  direct  the  transfer  of  information  and  to 
store  the  messages  as  Aey  are  being  processed.  The  amount  of  space  required  shall  be 
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clq)endrat  on  the  maximum  number  of  send  and  receive  messages  possiUe  for  a  particular 
segmraL  These  numbers  shall  be  deflned  by  the  segment  when  the  I/O  requirements  are 
established  using  the  Define_A_Message_Rec(xd_For  application  service. 

3. 1.7. 8.6  Receive  Messages.  Messages  shall  be  received  from  the  global  bus  and 
passed  through  tire  BIU  to  the  application  layer  software.  The  media  heac^  and  trailers 
shall  be  removed  from  the  messages  before  they  are  passed  to  the  application  layer.  The 
status  field  of  each  receive  message  shall  be  monitored  by  the  BIU  untU  a  message  is  found 
that  has  been  transmitted  correcUy.  When  the  status  indicates  that  a  message  has  been 
received  correctly,  the  message  shall  be  processed.  If  the  status  indicates  that  the 
transmission  was  terminated  prematurely,  a  new  receive  operation  shall  be  established  to 
await  anotlrer  transmission  of  the  data.  Errors  shall  be  processed  as  they  occur  without 
degradation  of  module  operation. 

3. 1.7. 8.7  Send  Messages.  Messages  sent  from  the  application  layer  software  to  the 
bus  through  the  BIU  shall  comply  with  the  particular  service  request^  by  the  segment 
Media  headers  and  trailers  shall  be  added  to  the  messages  before  they  are  passed  to  the 
transfer  layer.  The  status  of  the  outstanding  message  transfers  shall  be  monitored,  and  the 
appropriate  action  shall  be  taken  based  on  this  status  to  prevent  operational  failure  of  the 
module. 

3.1. 7.8.8  Translate  Messages.  Any  necessary  message  data  translations  shall  be 
performed  by  the  session  layer.  The  data  shall  be  transferred  to  the  host  by  means  of  the 
application  services.  The  reverse  shall  be  true  whra  sending  messages. 

3.1.7.9  Transfer  Layer.  The  transfer  layer  shall  implement  XTP  as  specified  in  PEI 
89-103  Rev  3.5,  the  most  current  version  of  XIP  or  an  equivalent  protocol. 

3. 1.7.9. 1  Transfer  Layer  Functions.  The  transfer  layer  relates  to  the  ISO/OSI 
reference  model's  network  and  transport  layers.  The  transfer  layer  shall  include  the 
interface  to  the  session  layer  and  the  logical  link  control.  The  following  functions  and 
services  shall  be  provided: 

a.  Real-time  datagram  service. 

b.  Flow/error/rate  control. 

c.  Selective  re-transmissioiL 

d.  Accommodation  of  multiple  addressing  schemes. 

e.  Message  boundary  preservation. 

f.  Out-of-band  signaling. 

g.  Reliable  multi-cast  mechanism. 

h.  Traditional  stream  services. 

The  transfer  layer  protocol  shall  provide  for  all  of  these  functions  and  services. 

3.1. 7.9.2  Physical  Implementation.  The  physical  implementation  of  the  Transfer 
Layer  shall  be  determined  by  an  engineering  ansdysis  of  available  technical  alternative  for 
cost  performance. 
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3.1.7.10  Physical  Media  Layer.  The  physical  layer  shaU  inccvpcM^  the  Logical  link 
Ccmtrol  (LLC)  and  the  communication  media. 

3.1.7. 10. 1  Logical  Liok  Control.  The  logical  link  control  shall  specify  the  interface 
between  the  communication  media  and  the  transfer  layer.  Hus  layer  is  specified  by  IEEE 

802.2  logical  link  control.  It  shall  permit  upgrade  changes  to  the  communication  media 
without  leconstructitm  of  the  transfer  layer. 

3.1.7.10.2  Communication  Media.  For  the  ARWA,  the  communication  media  shall  be 
the  FDDI.  There  are  four  documents  that  shall  specify  tte  construction  and  use  of  FDDI: 

a.  Media  Access  Control  -  ANSI  X3. 139- 1987 

b .  Physical  Layer  Protocol  -  ANSI  X3. 148- 1988 

c.  Physical  Layer  Medium  Dependent  -  ANSI  X3. 166-1989 

d.  Station  Management  -  ANSI  X3T9.5/84-49  Rev  5 

3. 1 .7. 10.2. 1  Media  Access  Control.  The  Media  Access  Control  (MAC)  document  shall 
be  used  to  define  the  controls  for  access  to  the  communication  media  and  define  a  common 
interface  between  these  controls  and  the  LLC. 

3.1.7.10.2.2  Physical  Laver  Protocol.  The  Physical  Layer  Protocol  (PHY)  document 
shall  be  used  to  describe  the  encoding  of  the  data  bits  on  the  communication  media.  The 
PHY  document  shall  also  be  used  to  define  the  symbols  and  data  bit  rate  for  the  network. 
The  PHY  shall  provide  the  connection  between  the  data  link  layer  and  the  Physical  Layer 
Medium  Dependent  (PMD)  and  establishes  clock  synchronization. 

3.1.7.10.2.3  Physical  Laver  Medium  Dependent.  The  Physical  Layer  Medium 
Dependent  (PMD)  shall  be  used  to  define  the  fiber  optic  cable,  wavelength  of  the  light, 
power  budgets,  optical  bypass  provisions,  characteristics  of  the  fiber  optic  drivers  and 
receivers,  connectors  and  keying.  The  PMD  shall  provide  all  services  necessary  to 
transport  a  suitably  coded  digits  bit  stream  from  module  to  module. 

3.1.7.10.2.4  Station  Management.  The  Station  Management  (SMT)  shall  be  used  to 
define  topology,  operation  of  network  performance  data  collection  and  analysis. 

3.1.7.10.3  General  Physical  Laver  Requirements. 

3. 1 .7. 10.3. 1  ARWA  Communication  Media  Topology.  The  topology  of  the  ARWA 
communication  media  shall  be  a  single  ring.  A  redundant  ring  topology  shall  not  be 
provided. 

3.1.7.10.3.2  Media  Access  Protocol.  MAC  shall  be  the  lower  layer  of  the  data  link  layer. 
The  upper  half  of  the  data  link  layer  shall  be  LLC.  Hie  MAC  shall  interface  to  the  LLC  as 
defined  in  IEEE  802.2. 

3. 1 .7. 10.3.2. 1  Token  Control.  The  token  rotation  timer  shall  be  a  maximum  of  1.0 
millisecond.  The  method  used  to  set  this  token  rotation  timer  in  each  module  BIU  and  the 
actual  token  rotation  timer  value  shall  be  determined  by  engineering  analysis  to 
accommodate  the  design. 
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3.1.7.11  Intennodiile  Interfaces.  The  intennodule  interfaces  shall  be  as  defined  in  the 
Interface  Design  Documents. 

3.1.8  Government  Furnished  Property.  Government  furnished  property  shall  be 
identified  as  required  for  development  of  the  ARWA  SS. 

3.1.9  Interface  Requirements.  The  ARWA  SSM  design  shall  be  implemented  in  a  manner 
consistent  with  the  functional  allocation  and  interfacing  rules  of  the  generic  Modular 
Simulator  System  (MSS).  The  following  paragraphs  describe  the  inter-segment 
communication  requirements  for  the  ARWA  ^vice.  These  requirements  are  applicable  to 
all  segments  within  the  ARWA  device. 

3. 1.9.1  MSS  Segment  Interfaces.  The  MSS  interface  specification  is  composed  of 
interface  requirements  and  data  requirements.  The  interface  requirements  specify  broad 
system  level  requirements  such  as  synchronization,  timing,  protocols,  and  hardware 
interfaces  applicable  to  all  segments.  The  focus  of  the  interface  requirements  is  on  inter¬ 
segment  communication,  wUch  occurs  via  the  VNET.  The  interface  requirements  also 
address  issues  relating  to  interfacing  with  hardware  configuration  items  (HWCI)-  The 
focus  of  the  data  requirements  is  on  inter-segment  communication,  specifying  the  various 
data  elements  (i.e.,  messages)  passed  between  the  segments  via  the  VNET. 

The  MSS  concept  levies  no  requirements  for  intra-segment  interfaces.  However,  the 
following  general  guidelines  shoidd  be  used; 

a.  Intra-segment  interfaces  should  support  the  inter-segment  messages, 

b .  Intra-segment  interfaces  should  reflect  the  design  partition,  and 

c .  Intra-segment  interfaces  should  not  interfere  with  external  interfaces 
or  be  u^  outside  the  segment 

The  design  of  inter-segment  communication  is  located  in  the  ARWA  IDD. 

3. 1.9.2  Synchronization  and  Timing.  Each  segment  shall  assume  execution  as  a 
"black"  box  component  i.e.,  no  segment  design  shall  assume  that  any  particular  subset  of 
segmoits  have  executed  before  or  execute  after  the  segment 

3. 1.9.2. 1  Synchronization.  All  system  level  timing  and  synchronization  shall  be 
initiated  by  the  Control  segment  The  Control  seginent  shall  provide  a  top  priority 
broadcast  synchronization  message,  known  as  "clock  tick"  message,  at  the  beginning  of 
each  frame.  The  frequency  of  the  synchronization  message  shall  be  60  Hertz.  The  fonnat 
and  definition  of  the  synchronization  message  shall  be  as  defined  in  the  ARWA  device 
IDD.  Each  segment  sh^  commence  execution  of  the  software  for  the  corresponding  fiame 
upon  receipt  of  the  synchronization  message. 

The  synchronization  message  shall  be  generated  by  the  Control  segment  and  transmitted  to 
all  segments  when  in  the  system  mode,  remote  controlled  diagnostic  mode,  simulation 
mode,  and  shutdown  mode. 

Intra-segmnet  synchronization  methodologies  (internal  to  each  segment)  are  not  to  be 
constrained  by  this  specification  so  long  as  such  methodologies  meet  or  exceed  the 
requirements  specified  herein. 

3. 1 .9.2.2  Timing.  The  following  timing  requirements  shall  apply  to  all  segments  in 
the  ARWA  device: 
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a.  The  base  rate  and  highest  iteration  rate  for  the  device  shall  be  60  Ifertz. 

This  is  the  rate  of  the  synchronization  (clodc  tick)  message  (m  die  VNET 
and  the  frame  rate.  Segment  internal  processing  shall  be  cmducted 
sufficient  to  ensure  that  the  segment  input/output  is  [Nxivided  at  the 
specified  rate. 

b.  Message  transmission  within  a  frame  via  the  VNET  shall  be  distributed. 

This  means  that  when  a  segment  completes  the  computations  which  would 
allow  a  message  to  be  transmitted,  the  segment  shall  send  that  message 
immediately.  Segments  shall  not  wait  until  the  rad  of  the  frame  to  transmit 
their  messages. 

c.  All  message  transmissions  for  a  segment  in  each  frame  shall  start  no  sooner 
than  1.0  milliseconds  after  frame  start  This  requirement  is  not  applicable  to 
the  synchronization  (clock  tick)  message,  which  shall  always  start  each 
frame. 

d.  Segment  processing  shall  be  evenly  loaded  ot  balanced  among  the  available 
simulation  frames  within  a  cycle  (a  cycle  being  the  total  number  of  frames  in 
one  second).  Tte  frame  assignments  for  each  segment  shall  be  designed  to 
allow  for  additional  fine  tuning  adjustments  to  the  specified  frame 
assignments  during  system  integration,  so  as  to  more  evenly  distribute 
VNCT  traffic  throughout  the  simulation  cycle. 

3. 1. 9.2.3  Cue  Correlation.  Simulated  cues  for  the  device  shall  have  no  noticeable 
errors  in  conelatable  factors  such  as  time,  position,  velocity,  or  acceleration.  As  a 
minimum,  all  cues  provided  by  the  Physical  Cues  segment.  Visual  segment  and  Flight 
Station  segment  shall  be  properly  synchronized  with  all  other  segments.  These  cues  shall 
be  correlate 

Cue  correlation  transport  delay  (delay  between  any  synchronized  cue)  shall  be  minimal, 
including  the  inherent  delay  of  Ae  installed  visu^  system.  The  system  shall  respond  to 
abrupt  pitch,  roll  and  yaw  inputs  within  the  specified  transport  delay,  but  not  before  the 
time  when  tiie  actual  aircraft  would  have  responded  under  the  same  conditions. 

All  visual  scene  changes  from  a  steady  state  condition  shall  occur  within  the  specified 
tran^xMt  delay  but  not  before  the  resultant  physical  cue  onset 

3. 1.9.3  Inter-Segment  Communication  Protocol.  All  inter-segment  communication 
in  the  ARWA  device  shall  be  via  the  VNET.  The  VNET  sh^  serve  as  the  only 
communication  path  between  segments.  The  specific  implementation  and  design  of  the 
VNET  shall  be  transparent  to  the  individual  se^ents.  E^h  segment  shall  communicate 
with  the  VNET  using  the  inter-segment  interfaces  and  a  set  of  common  interface  processing 
services  that  will  allow  each  segment  to  send  messages,  receive  messages,  and  perform 
other  frmctions  as  required  by  the  application.  The  VNET  interface  processing  services  are 
calleo  ^plication  Services  and  are  fully  discussed  in  the  ARWA  SSM IDD. 

3. 1.9.4  HWCI  hiterface  Requirements.  The  ARWA  device  interfaces  with  HWCIs 
shall  be  accomplished  in  accordance  with  the  rules  described  in  the  following  paragraphs. 

3. 1 .9.4. 1  General  Purpose  Data  Controls  and  Displays.  The  ARWA  device  general 

purpose  controls  and  displays  shall  interface  via  the  Flight  Station  segment.  The  Flight 
Station  segment  shall  be  responsible  for  processing  such  data  as  required  to  drive  the 
displays  and  report  status  of  controls.  All  other  segments  shall  send  and  receive  control 
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and  display  data  to  and  from  the  Flight  Station  segment  via  the  VNET.  Such  data  shall  be 
in  the  fonn  of  engineering  units,  as  specified  in  the  ARWA  SSM IDD,  Appendix  A.  The 
Flight  Station  segment  shall  be  responsible  for  processing  this  data  as  required  to  drive  the 
control  or  display  to  the  respective  position  or  indication. 

3.1. 9.4.2  Tightly  Coupled  Controls  and  Displays.  The  ARWA  device  tightly  coupled 

controls  and  displays  shall  interface  via  a  dedicated  back-door  interface  to  the  associated 
segments  and  not  via  the  VNET  to  the  Flight  Station  segment  The  affected  segment  diaU 
be  responsible  for  processing  the  data  necessary  to  drive  displays  and  report  status  of 
controls.  Tightly  coupled  controls  and  displays  are  those  for  which  control  and  display  are 
both  dedica^  and  complex.  The  performance  of  the  such  devices  are  highly  integrated 
with  the  performance  of  related  simulations  in  the  associated  segments.  Examples  of  such 
devices  are  those  which  are  tightly  coupled  to  a  specific  function  in  a  particular  segment, 
such  as  dedicated  Control  Display  Units  (CDUs),  primary  flight  controls  (stick,  rudder), 
threat  warning  display  computers,  etc.  The  interface  requirements  for  tightly  coupled 
controls  and  (hsplays  shall  also  apply  where  transport  delay  must  be  minimized.  TighUy 
coupled  controls  and  displays  applicable  to  the  SSM  include  the  control  loading  system 
connected  to  the  Flight  Controls  segment  and  the  sound  system  connected  to  the  Physical 
Cues  segment 

3. 1 .9.5  Coordinate  System.  The  coordinate  system  utilized  on  the  ARWA  device 
VNET  shall  be  a  Flat  Earth  coordinate  system.  Individual  segments  which  use  other 
coordinate  systems  internally  shall  perform  any  transformation  necessary  to  conform  to  the 
Rat  Earth  system,  when  communicating  such  information  via  the  VNET. 

3. 1.9.6  Data  Requirements.  The  following  paragraphs  defme  requirements  for 
interfaces  between  ARWA  device  segments  via  the  VNET.  The  interfacing  data  elements 
shall  be  "messages."  A  message  is  a  data  structure  that  bundles  many  separate  data  items 
into  an  Ada  computer  language  record  which  defines  a  unified  interface.  The  speciHc 
contend  of  each  field  of  the  data  elements  (messages)  in  the  interface  messages,  including 
units,  limits,  ranges,  accuracy  ,  precisions,  resolutions,  and  names  shall  be  as  defined  in 
the  ARWA  SSM  IDD. 

3. 1.9.6. 1  Message  Theory.  The  MSS  segments  communicate  via  a  set  of  well- 
defined  messages.  The  messages  shall  be  defined  by  the  originating  segment  Appendix  A 
of  the  ARWA  SSM  IDD  captures  the  design  details  of  each  message.  The  interface 
messages  used  within  the  ARWA  device  shall  meet  the  following  general  requirements: 

a.  The  interface  shall  facilitate  independent  segment  development 
Independent  segment  development  requires  interfaces  which  contain 
sufficient  detailed  information  and  stability  to  allow  each  segment 
designer  to  develop  and  test  their  segment  as  a  stand-alone  unit 

b.  The  interface  shall  be  well-defined.  Therefore,  the  ARWA  device  shall 
utilize  interfaces  specified  in  compilable  Ada  computer  language  in 
accordance  with  MIL-STD-1815A. 

c.  All  interfaces  shall  have  only  one  owner.  Therefore,  the  interface 
design  shall  assign  origination  responsibility  of  each  interface  message 
to  a  single  segment 

d.  The  interfaces  shall  be  grouped  according  to  purpose.  Therefore,  the 
interface  design  shall  group  (or  package)  interfaces  by  assigned  segment 
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e.  The  interfaces  shall  demonstrate  support  for  the  synchrtHiization  and  timing 
requirements.  Therefore,  the  interface  design  shall  ctefine  not  mily  the 
content  buy  also  the  suggested  rate  of  data  transfer  between  segments. 

f .  The  interfaces  shall  be  flexible  so  as  not  to  limit  various  segment  designs. 
Therefore,  the  interface  design  shall  specify  the  name,  land,  class,  and 
segment  allocation  of  the  messages.  Appendix  A  of  the  ARWA  SSM IDD 
sh^  deHned  the  specific  content  of  each  message. 

g.  The  interfaces  shall  be  usable  with  different  kinds  of  data  transmission 
media  and  methods.  Therefore,  the  interface  design  shall  reuse  the  generic 
message  structure  stated  in  the  MSS  IDD  and  shall  specify  the  instantiation 
of  the  VNET  in  the  ARWA  SSM  IDD. 

3.1. 9.6.2  Interface  Messages.  The  segment  interface  messages  for  the  ARWA  device 
shall  be  as  defined  by  the  detailed  interface  data  for  each  message  specified  in  Appendix  A 
of  the  ARWA  SSM  IDD. 

3.1. 9.6.3  Excluded  Data.  Digital  video  data,  graphical  imaging  data,  and  other 
unprocessed  data  shall  not  be  transmitted  via  the  VNET  during  real-time  operation. 
Graphical  imaging  data  includes  streams  of  lines  and  symbols,  streams  of  range,  elevation 
and  azimuth  angles.  All  data  transmitted  via  the  VNET  shall  be  as  defined  in  Appendix  A 
of  the  ARWA  SSM  IDD. 

3.1.10  System  Capability  Relationships.  The  SSM  system  capability  relationships 

shall  be  as  stated  in  the  following  paragraphs.  The  SSM  comprises  a  set  of  functions 
which  simulates  the  functional  and  performance  characteristics  of  Ae  ARWA  aircraft  Each 
simulation  function  shall  simulate  the  functional  and  performance  attributes  of  the  aircraft  in 
accordance  with  design  criteria.  Where  design  criteria  is  not  available  engineering 
assumptions  shall  be  made.  These  assumptions  shall  be  documented.  Individud 
simulation  functions  shall  be  assigned  to  one  and  only  one  segment  Transitions,  or  hand- 
offs,  of  simulation  functions  shall  not  be  allowed.  The  prede^ed  functional  allocation  to 
segments  shall  be  adhered  to. 

3.1.10.1  Common  Processing  Service  Functions.  Common  processing  service 
functions  are  special  functions  that  are  allocated  to  a  speciHc  segment  Service  functions 
provide  a  common  processing  service  for  several  segments  in  the  system.  The  results  are 
transmitted  across  the  VNET  for  use  by  other  segments.  Each  service  function  shall  be 
assigned  to  a  specific  segment;  that  assignment  shall  not  be  transferred  to  any  other 
segment  A  segment  may  provide  itself  with  a  service  function  instead  of  utilizing  the 
system  service  function.  This  shall  be  allowed  as  long  as  system  Hdelity  is  not 
deteriorated. 

Service  functions  shall  be  assigned  for  the  ARWA  MSS,  as  follows: 

a.  Occulting  Function.  This  function  shall  be  provided  by  the  Environment 
segment  Occulting  service  function  requirements  applicable  to  the 
ARWA  SSM  shall  include  terrain  occulting  only.  Owulting  of  electronic 
signals  and  cultural  features  is  not  required. 

b .  Spatial  Relations  Function.  This  function  shall  be  provided  by  the 
Environment  segment  Spatial  Relations  service  function  requir^rats 
applicable  to  the  ARWA  SSM  shall  include  a  straight  Line-Ctf-Sight  (LOS) 
distance  calculation  from  the  ownship  to  the  object  of  interest 
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c.  Visual  Database  Function. 

3.1.10.2  Common  Databases.  Access  to  common  databases  shall  be  via  back-door 
connections  from  the  individual  segments  to  the  database.  A  single  segment  shall  be 
assigned  the  responsibility  for  controlling  the  shared  database.  Common  databases  may  be 
accessed  through  a  back-door  interface,  however,  they  shall  not  be  modified,  except  by  the 
controlling  segment,  during  real-time  operations.  This  does  not  preclude  downloading  of 
databases  between  segments  across  the  VNET  or  a  back-door  bus  during  non-real-time 
operation.  Files  for  diagnostics  may  be  passed  in  the  same  manner. 

3.2  System  Characteristics.  System  characteristics  shall  be  in  accordance  with  the 
contractor's  best  commercial  practices  standards  and  other  primary  references  as  specified 
herein.  Military  standards  referenced  herein  shall  be  used  only  for  reference  and  as  guides 
in  meeting  the  requirement 

In  order  to  minimize  cost  risk,  and  development  time,  commercial  off-the-shelf  equipment 
that  is  fully  supported  by  the  manufacturer  shall  be  used  whenever  it  meets  the 
requirements  of  this  specification.  The  use  of  commercial  off-the-shelf  equipment  for 
processing  resources  shall  meet  the  requirements  as  specified  in  paragraph  3.3  of  this 
specification. 

Commercial  off-the-shelf  equipment  shall  be  exempt  from  the  parts  control  and  hardware 
standardization  requirements  of  this  specification.  However,  its  use  shall  not  preclude  the 
ARWA  SS  from  meeting  all  other  requirements  of  this  specification. 

3.2.1  Physical  Requirements 

3.2. 1 . 1  General.  The  ARWA  SS  shall  be  of  modular  construction,  with  the  major 
components  connected  by  cable  assemblies  and  electrical  lines,  as  required,  to  provide 
flexibility  in  the  general  arrangement  of  the  equipment  Special  tools  or  equipment  should 
not  be  required  for  assembly  or  disassembly  of  the  major  components.  If  such  tools  or 
equipment  are  required,  they  shall  be  provided  as  support  equipment  and  identified  as  such. 
A  means  shall  be  provided  for  leveling  each  major  component  if  such  components  require 
leveling.  The  device  shall  be  designed  to  allow  maintenance  accessibility  for  all  items  that 
will  require  maintenance. 

3.2. 1.2  Lighting.  All  ARWA  unique  lighting  required  for  operation  and 
maintenance  of  the  device  shall  be  provided.  Lighting  controls  shall  be  provided  for  all 
ARWA  unique  lighting.  Crew  station  functional  lighting  components  shall  duplicate  those 
found  in  the  simulated  aircraft  Supplementary  lighting  shall  be  provided  in  any  area  where 
maintenance  may  be  required  and  where  ambient  lighting  is  insufficient  Open  bulbs  shall 
be  guarded  against  accidental  breakage  and  personnel  contact 

3.2. 1.3  Climate  Control.  Heating/cooling  shall  be  provided  for  ARWA  SS 
equipment  that  require  more  than  the  simulator  facility  heating/cooling  systems 
requirements  stated  in  paragraph  3.2.2  of  this  specification.  Duct  work  and  associated 
equipment  to  tie  into  the  System  shall  be  provided  and  installed  as  necessary.  Operational 
controls  shall  be  provided  for  all  ARWA  SS  heating/cooling  systems  as  necessary. 

3.2. 1.4  Size.  The  size  of  the  ARWA,  including  device  dedicated  computational 
equipment,  shall  be  no  greater  than  a  sixteen  foot  cube. 
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3.2. 1 .5  Color.  The  paint  to  be  used  on  the  ARWA  SS  shall  be  from  the  semi  gloss 
series  of  FED-STD-595.  There  are  no  specific  color  requirements  for  this  particular 
application.  All  paint  shall  be  applied  using  best  commercial  practices  for  durability  and 
adhesion.  Paint  >^1  be  compatible  with  NVGs. 

3.2. 1.6  Nameplate  And  Product  Markings.  Nameplate  and  product  markings  shall 
be  in  accordance  with  best  commercial  practices.  All  components  shall  be  part  marked  for 
easy  identification.  Nameplates  shall  be  provided  for  each  ARWA.  All  markings  shall  be 
of  a  durable  nature  and  not  easily  removed. 

3.2. 1.7  Mechanical  Design.  The  following  paragraphs  describe  the  mechanical 
design  requirements  which  are  applicable  to  the  construction  of  the  ARWA  SS. 

3. 2. 1.7.1  Mounting.  Mounting  requirements  shall  be  in  accordance  with  best 
commercial  practices. 

3.2. 1.7.2  Protection.  Protection  of  parts  and  assemblies  shall  be  in  accordance  with 
best  commercial  practices  and  shall  provide  for  protection  of  parts,  chassis  protection,  and 
vibration  and  shock  protection. 

3.2. 1.7.3  Enclosures.  Enclosure  design  shall  be  in  accordance  with  best  commercial 
practices  and  shall  include  removable  panels  and  cover  plates. 

3.2. 1 . 8  Electrical  And  Electronic  Design.  The  following  paragraphs  describe  the 
electrical  and  electronic  design  requirements  which  are  applicable  to  the  construction  of  the 
ARWA 

3.2.1. 8.1  General.  Electrical  and  electronic  equipment  design,  design  and 
construction  of  printed  circuits  and  printed  circuit  boards,  and  electronic  equipment  thermal 
design  shall  be  in  accordance  with  test  commercial  pr^tices. 

3.2. 1.8.2  Circuit  Design.  Circuit  design  shall  be  in  accordance  with  best  commercial 
practices. 

3.2. 1.8.3  Circuit  Protection.  Circuit  protection  shall  be  in  accordance  with  best 
commercial  practices  and  shall  be  designed  with  safety  of  personnel  as  a  priority. 

3.2. 1 .8.4  Primary  Power  Source.  A  source  of  primary  power  in  the  trainer  facility 
shall  be  provided  by  the  Govenunent.  The  simulation  device  equipment  shall  be  designed 
to  operate  from  this  primary  power  source.  The  ARWA  SS  shall  not  cause  an  excessive 
power  surge  during  start-up.  Distribution,  internal  supply  voltages,  and  conditioning  of 
the  power  within  the  ARWA  SS  shall  be  provided. 

3.2. 1.8.5  Electrical  Bonding.  Electrical  bonding  shall  be  designed  in  accordance  with 
best  commercial  practices. 

3. 2.1. 8. 6  Grounding.  The  grounding  system  in  the  ARWA  SS  facility  shall  be 
supplied  by  the  Government.  A1  ARWA  SS  grounding  systems  shall  terminate  on  the 
facility  grounding  system  and  comply  with  the  National  Electrical  Code.  Grounding  for 
personnel  protection  shall  be  accomplished  within  the  ARWA  SS  power  distribution 
system. 

3.2. 1.8.7  Wiring  And  Cabling.  Wiring  and  cabling  shall  comply  with  best 
commercial  practices.  The  selection  and  application  of  interconnecting  wires  and  cables 
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shall  be  in  accordance  with  the  National  Electrical  Code.  The  wire  temperature,  current 
carrying  capacity,  and  voltage  drop  requirements  shall  be  in  accordance  with  the  National 
Elet^c^Code. 

3.2. 1.8. 8  Connections.  Connections  and  Wire  terminations  for  mechanical 
connections  shall  be  designed  in  accordance  with  best  commercial  practices. 

3.2. 1.8.9  Identification  Of  Conductors.  Electrical  conductors  shall  be  identified  in 
accordance  with  best  commercial  practices.  Coding  of  conductors  and  wire  terminal  ends 
shall  be  in  accordance  with  best  commercial  practices  ot  the  National  Electrical  Code. 

3.2.1.8.10  Identification  Of  Components.  Electrical  components  shall  be  identified  in 
accordance  with  best  commercial  practices 

3.2. 1.9  Optical  Design.  Optical  equipment  design  and  optical  coatings  shall  be  in 
accordance  with  best  commercial  practices. 

3.2.1.10  Communication  Equipment  Design.  The  simulator  communication  system 
design  shall  be  in  accordance  with  best  commercial  practices  and  shall  replicate  the 
communication  system  of  the  application  aircraft  to  the  fidelity  required  to  support  the 
simulator  mission.  A  maintenance/emergency  intercom  syster i  shall  be  provided.  This 
System  shall  allow  for  priority  voice  communication  between  the  Simulation  Manager  and 
eachARWA. 

3.2.2  Environmental  Conditions.  The  trainer  shall  be  designed  to  operate  in  a  controlled, 
stable  environment  where  the  temperature,  relative  humidity,  and  barometric  pressure  are 
maintained  within  the  following  liinits: 

a.  Temperature 

(1)  operating:  21  degrees  C  +/-  4  degrees  C 

(2)  non-operating:  -29  degrees  C  to  54  degrees  C 
( excluding  visual  system) 

b.  Relative  HumidiQr 

(1)  operating:  50%  +/-  20%  non-condensing 

(2)  non-operating:  up  to  100%  with  condensation 

c.  Barometric  Pressure 

(1)  operating:  31.35  to  24.9  inches  Hg 

(2)  non-operating:  3 1 .35  to  5.5  inches  Hg 

3.2.3  Nuclear  Control  Requirements.  There  are  no  nuclear  control  requirements 
applicable  to  the  ARWA  SS. 

3.2.4  Materials.  Processes  and  Parts.  The  following  paragraphs  describe  the  materials, 
processes  and  parts  requirements  which  are  applicable  to  the  construction  of  the  ARWA 
SS. 

3.2.4. 1  General.  Neither  asbestos  material  nor  parts  containing  asbestos  shall  be 

used  in  the  ARWA  SS.  The  contractor  shall  have  the  option  of  using  aircraft  parts  in  the 
design  whenever  it  is  determined  to  be  cost  effective.  Peculiar  materials,  parts  and 
processes  that  are  used  in  the  ARWA  SS  shall  be  controlled  by  specifications  that  shall  be 
referenced  to  the  drawings  controlling  the  device  configuration. 
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3.2.5  Electromagnetic  Radiation.  The  design  of  the  equipment  shall  be  in  accordance 
with  the  suppliers  normal  practice  and  shall  ensure  that  the  trainer  components  are  mutually 
compatible.  The  filtering  of  primary  power  supplies  and  screening  ^all  be  such  that  tte 
sim^ator  is  not  susceptible  to  an  electromagnetic  environment,  nor  emits  interference 
sufficient  to  adversely  effect  the  performance  of  neighboring  equipment. 

3.2.6  Workmanship.  The  contractors  standard  processes  and  procedures  and  i^uirement 
9  of  MIL-STD-4S4  shall  be  used  as  a  guide  for  worionanship.  Particular  attention  shall  be 
given  to  neatness,  thoroughness  of  soldering,  wiring,  welding,  forming,  machining,  and 
assembly  of  parts.  Units  shall  be  thoroughly  cleaned  of  loose,  spattered,  or  excess  solder, 
metal  ctups,  and  other  foreign  material  a^r  assembly.  Burrs,  sharp  edges,  and  resin  flash 
shall  be  removed. 

3.2.7  Interchangeability.  Mechanical  and  electrical  subassemblies,  components  and  parts 
that  have  identical  part  numbers  shall  be  interchangeable  or  replaceable  and  shall  possess 
both  mechanical  and  electrical  compatibility  to  permit  their  installation  as  interchangeable 
subassemblies  and  parts  without  regard  to  the  manufacturer  or  supplier.  Supplied  parts 
shall  not  require  reconEguration  or  Enish  assembly  in  any  manner  prior  to  actual  use  with 
the  exception  of  commercial  off-the-shelf  parts.  Each  part  number  shall  be  unique  where 
configuration  differences  exist.  The  supplier  shall  be  responsible  to  ensure  parts 
replaceability  for  all  supplied  parts  off-the-stelf  or  otherwise. 

3.2.8  Safety.  The  trainer  design  shall  be  in  accordance  with  MIL-T-23991  "Safety" 
p.2.1.2)  which  shall  be  used  as  a  guide  for  the  trainer  design.  Safety  features  shall  be 
installed  in  the  ARWA  SS  to  protect  personnel  and  equipment.  Fire  detection  and 
suppression  systems  shall  be  provided  with  an  audible  ^arm.  The  fire  detection  system 
shall  consist  of  smoke  and  overheat  detection  equipment  of  a  low  cost  commercially 
available  nature.  The  system  shall  detect  smoke  and  overheat  conditions  in  equipment 
cabinets  and  ARWA  user  areas.  When  a  detection  occurs,  the  affected  equipment  shall 
automatically  be  transitioned  to  a  power  off  state.  Fire  suppression  shall  consist  of 
overhead  water  sprinklers  in  enclosed  personnel  areas  not  already  protected  by  existing 
facility  fire  suppression  systems.  Sprinkler  systems  shall  not  be  used  to  extinguish 
electrical  fires.  For  such  fires  the  appropriate  National  Fire  Prevention  Association 
(NFPA)  manual  fire  extinguisher  shall  be  provided  and  placed  in  close  proximity  to  the 
possible  use  area.  A  halon  system  shall  not  be  provided. 

3.2.8. 1  Emergency  ON/OFF  Power  Switches.  An  emergency  ON/OFF  power 
switch  shall  be  provided  for  the  crew  station,  the  Simulation  Manager  station,  every 
equipment  rack,  and  any  remote  area  where  personnel  may  be  working  that  is  unique  to  the 
particular  design.  The  switches  shall  be  clearly  marked  and  readily  accessible,  but 
protected  from  inadvertent  actuation. 

3.2.8.2  Control  Loading.  The  control  loading  system  shall  be  designed  to  prevent 
rapid  or  forceful  uncommanded  control  displacements  upon  energizing  the  system,  during 
automatic  retrimming,  following  inadvertent  start-up  from  an  untrimmed  condition,  or  as  a 
result  of  either  an  electrical  or  mechanical  system  fafiure,  to  avoid  injury  to  posoimel. 

3.2.9  Human  Performance/Human  Engineering.  The  principles,  procedures  and  criteria 
of  hmnan  engineering  and  life  support  shall  be  applied  to  the  d^ign  and  development  of  the 
ARWA  SS  to  ensure  that  the  System  can  perform  assigned  functions  efficiently,  reliably 
and  safely.  The  design  shall  be  in  accordance  with  the  intent  of  MIL-H-  46855  (applicable 
sections)  and  MIL-STD-1472  (applicable  sections).  The  human  performance  and  life 
support  requirements  shall  consider  the  important  aspects  of  operability,  maintainability, 
safety,  and  cost  factors. 
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3.2.10  Deployment  Requirements.  Deployment  requirements  indicating  the 
number  of  trainer  installations  and  c^radng  locadcHis  shall  be  as  defined  in  the  contract 

3.3  Processing  Resources.  The  following  paragraphs  define  the  processing  resource 
requirements  which  are  applicable  to  the  ARWA  SS. 

3.3.1  General  Hardware  Requirements.  The  selection  of  all  processors  and  associated 
peripheral  devices,  including  their  interface  boards,  shall  limited  to  established 
commercial  off-the-shelf  equipment  that  is  fully  support^  by  the  manufacturer. 

The  processors  selected  shall  have  a  word  size  and  operating  speed  which  is  capable  of 
producing  cockpit  indications  and  cockpit  sensations  of  aircraft  performance,  as  well  as 
Support  System  displays  and  indications  that  are  free  of  discernible  stepping,  oscillating, 
jittering,  or  other  erratic  behavior,  while  meeting  the  performance  r^uirements  and 
tolerance  levels  described  in  this  specification.  Sufficient  installed  memory  shall  be 
provided  for  each  processor  so  that  the  processing  system  can  store  and  execute  the 
complete  operational  program  or  any  support  program,  and  still  meet  spare  requirements. 

Direct  access  mass  storage  equipment,  with  removable  storage  media,  shall  be  provided  as 
part  of  the  System.  The  media  ^all  be  removable  without  the  use  of  tools.  The  equipment 
shall  have  the  capability  of  storing  and  transferring  all  executable  operational  and  on-line 
diagnostic  software  without  remounting  storage  m^a.  The  complete  operational  program 
or  any  support  program  shall  be  able  to  be  transferred  to  installed  memoiy  within  five  (5) 
minutes. 

The  processing  system  shall  incorporate  power  interrupt  fail-safe  provisions.  An 
unexpected  loss  of  power  shall  not  result  in  any  damage  to  the  processors  or  associated 
peripheral  equipment  Recovery  shall  be  accomplished  within  a  reasonable  amount  of  time 
after  power  is  restored. 

The  SSM  computational  system  shall  provide  at  least  50%  spare  processing  capacity  in  the 
initial  delivery  baseline.  Each  individual  processor  within  a  modide  shall  provide  not 
less  than  25%  spare  processing  capacity  in  the  initial  delivery  baseline.  Each  module  shall 
provide  for  accomplishing  and  validating  the  clearing  of  classified  data  from  its  processors. 

The  SSM  computational  system  shall  provide  not  less  than  50%  spare  resident  RAM  in  the 
initial  delivery  baseline.  The  SSM  shall  provide  for  accomplishing  and  validating  the 
clearing  of  classified  data  from  its  resident  random  access  memory  (RA^. 

The  SSM  computational  system  shall  provide  sufficient  mass  storage  capacity  for  the  initial 
program  load  in  the  initid  delivery  baseline.  The  SSM  shall  provide  empty  expansion 
capability  to  double  the  available  mass  storage  capacity. 

The  SSM  computational  system  shall  provide  sufficient  interface  channel  capability  for  its 
backdoor  interfaces.  The  SSM  computational  system  shall  provide  empty  expansion 
capability  to  increase  the  number  of  interfaces  by  25%.  The  SSM  computational  system 
shall  provide  for  accomplishing  and  validating  the  clearing  of  classified  data  from  its 
interface  controllers. 

The  expansion  capability  requirements  in  the  foregoing  discussion  shall  be  met  by 
allocation  of  empty  slots  in  the  host  computer  chassis  of  the  SSM  computational  system, 
and  shall  not  be  met  by  double-allocation  of  slots. 
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There  is  no  mass  storage  requirement  for  the  SSM  driven  by  the  application  segments  or 
the  bus  interface  unit  The  specific  computational  architecture  may  require  embedded  mass 
storage. 

The  SSM  computational  system  shall  provide  for  an  Ethernet  interface.  The  SSM  shall 
provide  for  an  FDDI  interface  to  the  ARWA  VNET.  The  SSM  shall  provide  for  an  FDDI 
interface  to  the  DIS  Network.  The  SSM  shall  provide  for  an  appropriate  communication 
and  control  interface  to  the  control  loading  computer  located  in  the  flight  station  module. 
The  SSM  shall  provide  for  an  appropriate  communication  and  control  interface  to  the  audio 
electronics  device.  The  SSM  shall  provide  for  a  digital  voice  line  interface  from  the  audio 
electronics  to  the  DIS  Network  if  required. 

3.3.2  General  Programming  Requirements.  Software  developed  and  supported  by  a 
manufacturer  for  use  with  commercial  off-the-shelf  equipment,  or  software  ^at  is  itself 
commercial  off-the-shelf  equipment  shall  be  used  wheitever  it  is  compatible  with  the  overall 
design.  Newly  developed  software  and  software  modified  greater  than  50%  shall  be 
implemented  in  the  Ada  software  language.  Exceptions  shall  be  documented.  Support 
programs  shall  operate  independently  of  the  operational  program  and  shall  include  the 
following; 

a.  Diagnostic  features  and  diagnostic  programs  provided  by  equipment 
manufacturers  for  use  on  their  equipment. 

b.  Programs  to  perform  the  software  testing  as  required  by  the  verification  test 
procedures. 

c.  Programs  required  to  fulfill  the  requirements  stated  for  individual  support 
systems. 

d.  Programs  required  to  present  a  "user-friendly"  interface  to  support  systems 
software  (e.g.,  configuration  management,  parameter  editing, ...). 

Validated  Ada  compiler(s),  assemblers,  linkers,  and  software  support  tools  shall  be  used  to 
develop  Ada  software. 

3.4  Quality  Factors.  The  SSM  shall  meet  the  quality  factor  requirements  defined  in  the 
following  paragraphs. 

3.4.1  Reliability.  The  SSM  shall  be  designed  and  constructed  in  such  a  manner  to 
produce  a  reliable  end  item  using  the  contractor's  best  commercial  practices  as  a  guide. 
Commercial  off-the-shelf  products  of  proven  reliability  and  maturity  shall  be  used  when 
practical. 

3.4.2  Maintainability.  The  SSM  shall  be  designed  and  constructed  to  produce  a 
maintainable  end  item  using  the  contractors  best  commercial  practices  as  a  guide. 
Commercially  available  products  shall  be  used  in  the  design  when  practical.  Design 
commonalty  shall  be  considered  during  development  to  reduce  the  quantity  of  unique 
spares  and  support  equipment  required  to  maintain  the  SSM.  Proper  maintenance  access 
shall  be  incor^rated  into  the  design  to  increase  maintainability. 

3.4.2. 1  Software  Quality.  All  software  developed  for  the  SSM  or  existing  software 
used  in  the  SSM  that  is  modified  more  than  50%  shaJl  be  developed  in  the  Ada  software 
language  in  accordance  with  MIL-STD-1815A.  Ada  programming  language  requirements 
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are  not  applicable  to  unmodified  manufacturer’s  software  or  commercial  off-the-shelf 
software. 

3.4.2.2  Ada  Programming  Support  Environment.  Validated  Ada  compilers, 
assemblers,  linkers,  and  software  support  tools  shall  be  used  to  develop  Ada  software  for 
the  SSM. 

3.4.3  Flexibility  Expansion.  The  top  level  design  philosophy  for  this  device  shall 
include  features  which  will  facilitate  future  changes  and  uj^tes  to  remain  current  with  the 
application  aircraft. 

3.4.4  Availability.  The  ARWA  SS  shall  be  designed  and  constructed  to  minimize 
maintenance  and  repair  time. 

3.4.5  Portability.  The  device  shall  be  designed  to  withstand  transportation  in  a 
commercial  padded  van  over  representative  U.S.  highways. 

3.5  Logistics.  There  are  no  specific  logistics  requirements  applicable  to  the  ARWA  SS. 

3.6  Precedence.  In  the  event  of  a  conflict  between  the  requirements  in  documents 
referenced  herein,  the  requirements  of  this  specification  shall  take  precedence.  In  the  event 
of  a  conflict  between  requirements  internal  to  this  specification,  the  overriding 
requirement(s)  shall  be  determined  by  mutual  agreement  between  the  Government  and  the 
ARWA  SS  prime  contractor. 

3.7  Qualification.  Formal  qualification  testing  is  not  required  for  the  SSM.  The  SSM 
test  program  shall  be  based  upon  sequential  testing  which  minimizes  redundant  testing, 
and  reduces  the  probability  of  test  failure  at  the  system  level.  The  lest  concept  shall  include 
disciplined  control  of  test  configuration,  timely  conduct  of  test  events,  and  verification  of 
test  results  prior  to  beginning  the  next  phase  of  testing.  Testing  of  the  SSM  performance 
characteristics  shall  be  in  accordance  with  the  tests  identified  in  the  following  paragraphs. 
Details  of  the  test  program  shall  be  contained  in  the  ARWA  System  Test  Plan  (STPX  Test 
configuration  shaU  be  controlled  as  specified  in  the  ARWA  Configuration  Management 
Plan. 

3.7.1  Segment  Testing.  Each  segment  shall  be  individually  tested,  prior  to  SSM  level 
integration  testing,  to  ensure  the  requirements  of  Section  3  have  b^n  satisfied.  The 
following  testing  shall  be  accomplished  at  the  segment  level. 

a.  Segment  Development  Test  At  the  completion  of  segment  development  a 
set  of  segment  development  tests  shall  be  performed  for  each  segment  within  the  SSM. 
Each  segment  shall  be  tested  as  a  stand-alone  software  product  at  the  external  interface 
level.  Segment  development  tests  shall  be  completed  prior  to  advancing  into  the  next  phase 
of  testing.  The  segment  development  test  phase  shall  be  an  informal  test  phase  conducted 
solely  to  verify  compliance  with  Section  3  performance  requirements  for  the  applicable 
segment 

3.7.2  Integrated  Simulator  System  Module  Testine.  Integrated  SSM  testing  shall  be 
accomplished  to  ensure  the  requirements  of  Section  3  are  satisfied  by  the  SSM  as  an 
integrated  entity.  The  following  tests  shall  be  accomplished  at  the  integrated  SSM  level. 

a.  Integrated  SSM  Development  Test  Integrated  SSM  development  testing 
shall  consist  of  a  dry  run  of  all  SSM  acceptance  tests.  Integrated  SSM 
testing  shall  focus  on  compliance  with  the  SSM  external  interfaces 
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intemted  SSM  development  testing  shall  be  an  informal  test  frfiase  and 
shall  be  conducted  pritv  to  advancing  into  the  formal  SSM  ac^tance 
test  phase. 

b.  SSM  Accq)tance  Test  SSM  acceptance  testing  shall  omsist  of  the  SSM 
procuring  activity  accomplishing  the  acceptance  tests  formally  for  SSM 
aocq)tance. 

4.  VERinCATION  REQUIREMENTS 

4. 1  General.  The  following  paragraphs  define  the  general  verification  requirements  for 
theARWASS. 

4.1.1  Philosophy  of  Testing.  Testing  of  the  ARWA  SS  shall  consist  of  in-plant 
verification  testing  to  determine  speciflcation  compliance  of  the  ARWA  subsequent  to 
shipment  Verification  testing  shall  be  accomplished  by  performing  functional  and 
performance  evaluations  against  predefined  verification  criteria.  Performance  evaluations 
shall  be  specific  tests  designed  to  verify  subsystem  performance.  Acceptance  testing  shall 
consist  of  an  installation  and  checkout  activity  and  a  retest  period.  Hie  retest  sl^  be 
accomplished  by  performing  a  limited  subset  of  the  test  procedures  used  during  the 
verification  testing  functional  evaluations. 

4. 1.1.1  Testing  Events.  Scheduled  testing  shall  take  place  sequentially  in  the 
following  phases. 

4. 1.1. 1.1  Verification  Test.  Verification  testing  shall  be  accomplished  prior  to 
integration  of  the  ARWA  SSM,  VSM,  and  FSM.  The  testing  shall  ensure  that  the  System 
meets  the  functional  and  performance  requirements  of  each  volume  of  diis  specification. 

4. 1 . 1 . 1 .2  Acceptance  Test.  Site  acceptance  testing  shall  consist  of  installation  and 
checkout  of  the  System  at  the  Government  facility,  and  accomplishment  of  one  or  mote  of 
the  simulated  missions  conducted  during  verification  test  Acceptance  tests  and  associated 
acceptance  criteria  shall  be  mutually  agr^  upon  by  the  contractor  and  procuring  activity. 

4. 1 .2  Location  qf  Testing.  Verification  Testing  shall  be  accomplished  at  the  Loral  facility 
in  Orlando,  FL,  and  acceptance  testing  at  the  Government  facility.. 

4.1.3  Responsibility  for  Tests.  The  responsibility  for  testing  in  each  phase  of  testing. 

a.  Verification  phase.  The  prime  contractor  and  module  contractors  shall 
conduct  verification  testing.  Any  discrepancies  requiring  resolution,  as 
determined  by  mutual  agreement,  shall  be  corrected  by  the  prime  contractor 
or  the  module  contractor,  as  appropriate. 

b.  Acceptance  phase.  The  prime  contractor,  or  the  Government  at  its 
discretion,  shall  conduct  acceptance  testing.  Any  discrepancies  shall  be 
analyzed  for  simulator  performance  impact  and  appropriate  corrective  action 
agre^  to  by  the  Government  and  the  prime  contractor. 

4.1.4  Verification  Methods.  Verification  testing  shall  be  accomplished  by  one  or  mote  of 
the  following  methods: 

a.  Analysis.  This  method  consists  of  examining  engineering  design  data  such 
as  specifications,  drawings,  documented  customer  and  contractor 
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evaluations,  etc.,  in  order  to  determine  diat  the  design  will  satisfy  physical 
and  functional  requirements.  Analysis  is  performed  to  verify  perfcnmance 
characteristics  of  the  system,  module,  or  configuration  item.  Presentation 
of  prior  test  results  and  presentation  of  analysis  demonstrating  applicability 
to  the  current  system,  module,  or  configuration  item  shall  be  considered  a 
valid  analysis  technique. 

b.  Inspection.  This  method  consists  of  visual  examination  of  the  complete 
System  or  any  of  its  components,  in  order  to  determine  that  specified 
physical  requirements  have  been  satisfied.  Inspection  may  occur  during  any 
stage  of  the  development  process,  up  to  and  including  a  complete  system. 

c.  Demonstration.  This  method  ctmsists  of  operating  the  complete  System,  or 
any  of  its  components,  in  order  to  collect  data  to  determine  that  functional 
requirements  have  been  satisHed.  Demonstrations  may  occur  during  any 
stage  of  the  development  process,  up  to  and  including  a  complete  system. 

d.  Test  This  method  consists  of  operating  the  complete  System,  or  any  of  its 
components,  in  order  to  collect  data  to  determine  that  performance 
requirements  have  been  satisfied.  Tests  may  occur  during  any  stage  of  the 
development  process,  up  to  and  including  a  complete  system. 

4.2  Formal  Test  Formal  test  shall  consist  of  functional  and  performance  evaluations. 

4.2.1  Functional  and  Performance  Evaluations.  Evaluations  that  verify  the  fimctionality 
of  the  integrated  system  shall  be  performed  to  ensure  that  the  design  of  the  System  is  as 
specified  in  paragraph  3.1.1  of  this  volume  of  this  specification.  Functional  evaluations 
shall  consist  of  analyses  and  demonstrations  as  described  in  paragraph  4.1.4  above. 
Verification  of  the  design  requirements  shall  be  accomplished  by  operating  the  System  in 
the  appropriate  system  modes  and  states.  During  the  verification  event,  the  ARWA  SS 
functional  evaluations  shall  be  conducted.  Test  procedures  defining  mission  scenarios  and 
evaluation  criteria  shall  be  developed  and  used  to  verify  System  acceptability. 

Tests  shall  be  conducted  to  verify  the  performance  of  critical  System  elements  as  defined  in 
the  applicable  volumes  of  this  specification.  Performance  evaluations  shall  consist  of 
analyses,  inspections  and  tests  as  described  in  paragraph  4.1.4  above.  Test  procedures 
including  detailed  verification  criteria  shall  be  developed  and  used  to  verify  System 
performance. 

4.2.2  Reliability  and  Maintainability  Reliability  and  maintainability  demonstrations  shall 
not  be  performed. 

4.2.3  Verification  Cross  Reference.  Table  I,  ARWA  SSM  Verification  Cross  Reference 
Matrix,  provides  a  requirements/verification  cross  reference  guide  for  the  ARWA  SS  using 
the  definitions  provided  in  paragraph  4.1.4. 
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Legwid:  NA-N«  A|i|>Bc«bl«  Hn^wction  P-Demonitrilion  A-Aiulyiii  T-Twtj 


SectitmS 

Requitemens 

Refetmce 

atitm 

[s) _ 

Secti(»4 

Qualificati(» 

Requirement 

Reference 

NA 

IT 

TT 

3.1.7.10.2.1 

D 

4.2.1 

3.1.7.10.2.2 

D 

4.2.1 

3.1.7.10.2.3 

D 

4.2.1 

3.1.7.10.2.4 

D 

4.2.1 

3.1.7.10.3 

NA 

3.1.7.10.3.1 

D 

4.2.1 

3.1.7.10.3.2 

NA 

3.1.7.10.3.2.1 

D 

4.2.1 

3.1.7.11 

D 

4.2.1 

3.1.8 

1 

3.1.9 

NA 

3. 1.9.1 

D 

4.2.1 

3.1.9.2 

NA 

3.1.9.2.1 

D 

4.2.1 

3.1.9.2.2 

D 

4.2.1 

3.1.9.2.3 

D 

4.2.1 

3.1.9.3 

D 

4.2.1 

3. 1.9.4 

NA 

3. 1.9.4. 1 

D 

4.2.1 

3.1.9.4.2 

D 

4.2.1 

3.1.9.5 

D 

4.2.1 

3. 1.9.6 

NA 

3.1.9.6.1 

D 

4.2.1 

3.1.9.6.2 

D 

4.2.1 

3.1.9.6.3 

D 

4.2.1 

3.1.10 

NA 

3.1.10.1 

D 

4.2.1 

3.1.10.2 

D 

4.2.1 

3.2 

NA 

3.2.1 

NA 

3.2.1.1 

I 

4.2.1 

3.2.1.2 

I 

4.2.1 

3.2.1.3 

I 

4.2.1 

3.2.1.4 

I 

4.2.1 

3.2.1.5 

I 

4.2.1 

3.2.1.6 

I 

4.2.1 

3.2.1.7 

NA 

3.2.1.7.1 

I 

4.2.1 

3.2.1.7.2 

I 

4.2.1 

3.2.1.7.3 

I 

4.2.1 

3.2.1.8 

NA 

3.2.1.8.1 

I 

4.2.1 

3.2.1.8.2 

I 

4.2.1 

3.2.1.8.3 

I 

4.2.1 

Table  1.  SSM  Verification  Cross  Reference  Matrix 
[Continued] 
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Legend:  NA^oC  Applicabto  I-lnq^tion  D-Demonitratioa  A-Amlyiii  T-Tet| 


Sections 

Requiiemens 

Reforace 

Qualific. 

l^thodi 

idem 

_ 

Secti(»r4 

Qualification 

Requiiemrat 

Reference 

NA 

ir 

IT 

T 

3.2.1.8.4 

I 

4.2.1 

3.2.1.8.5 

I 

4.2.1 

3.2.1.8.6 

I 

4.2.1 

3.2.1.8.7 

I 

4.2.1 

3.2.1.8.8 

I 

4.2.1 

3.2.1.8.9 

I 

4.2.1 

3.2.1.8.10 

I 

4.2.1 

3.2.1.9 

I 

4.2.1 

3.2.1.10 

I 

4.2.1 

3.2.2 

D 

4.2.1 

3.2.3 

D 

4.2.1 

3.2.4 

NA 

3.2.4. 1 

D 

4.2.1 

3.2.5 

D 

4.2.1 

3.2.6 

D 

4.2.1 

3.2.7 

D 

4.2.1 

3.2.8 

NA 

3.2.8.1 

D 

4.2.1 

3.2.8.2 

D 

4.2.1 

3.2.9 

D 

4.2.1 

3.2.10 

D 

4.2.1 

3.3 

NA 

3.3.1 

D 

4.2.1 

3.3.2 

D 

4.2.1 

3.4 

NA 

3.4.1 

D 

4.2.1 

3.4.2 

NA 

3.4.2. 1 

D 

4.2.1 

3.4.2.2 

D 

4.2.1 

3.4.3 

D 

4.2.1 

3.4.4 

D 

4.2.1 

3.4.5 

D 

4.2.1 

3.5 

D 

4.2.1 

3.6 

A 

4.2.1 

3.7 

NA 

3.7.1 

D 

4.2.1 

3.7.2 

D 

4.2.1 

Table  1.  SSM  Verification  Cross  Reference  Matrix 
[Continued] 
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5 .  PREPARATION  FOR  DELIVERY 

5. 1  Preserving  and  Packaging.  Best  commercial  practices  .shall  he  iLsed  to  pre.serve  and 

package  the  device  in  order  to  ensure  that  there  will  be  no  damage  or  degradation  of 

performance  during  shipment 

5.2  Marking. 

Marking  of  assemblies  shall  be  in  accordance  with  the  intent  of  MIL- 

STD- 129  (applicable  sections).  Commercial  equipment  will  not  be  remarked. 

6.  NOTES 

6.1  Acronyms. 

ADS 

Air  Data  Subsystem 

ADSS 

Air  Data  Sensor  Subsystem 

ADST 

Advanced  Distributed  Simulation  Technology 

ADF 

Automatic  Direction  Finder 

ARWA 

Advanced  Rotary  Wing  Aircraft 

AFCS 

Automatic  Flight  Control  System 

AHRS 

Attitude  and  Heading  Reference  System 

AM 

Amplitude  Modulation 

ASE 

Aircraft  Survivability  Equipment 

ATHS 

Automatic  Target  Handover  System 

BDS-D 

Battlefield  Distributed  Simulation  -  Development 

C 

Centigrade 

CADC 

Centr^  Air  Data  Computer 

CDU 

Computer  Display  Unit 

CG 

Center  of  Gravity 

CNAV 

Coupled  Navigation  System 

CPG 

Copilot/Gurmer 

CWS 

Chemical  Warning  System 

db 

decibel 

D/F 

Direction  Finding 

DIS 

Distributed  Interactive  Simulation 

DNS 

Doppler  Navigation  System 

DOD 

Department  of  Defense 

DTV 

Day  Television 

DVO 

Di^t  View  Optics 

ECS 

Environmental  Control  System 

EIL 

Engineering  Topographic  Laboratory 

FDDI 

Fiber  Elistributed  Data  Interface 

FD/LS 

Fault  Detection/Location  System 

FLIR 

Forward  Looking  Infrared 

FM 

Frequency  Modulation 

FOR 

Held  of  Regard 

FOV 

Field  of  View 

GFP 

Government  Furnished  Property 

GPS 

Global  Positioning  System 

-  41  - 

March  31,  1994 


ADST/TR 

94-003276 

HARS 

Heading  and  Attitude  Reference  System 

Hg 

Mercury  (Barometric  Pressure) 

HF 

High  Frequency 

HOL 

Hi^  Order  Language 

HWCI 

Hardware  Configuration  Item 

ICS 

Intercom  Syst^ 

IDD 

Interface  Design  Document 

IFF 

Idoitification  Friend  or  Foe 

IFFC 

Integrated  Fire/Flight  Control 

VO 

Input/Ouq)ut 

lOS 

Instructor/Operator  System 

IR 

Infrared 

LAN 

Local  Area  Networic 

LF 

Low  Frequency 

LOS 

Line  of  Sight 

LPRF 

Laser  Pulse  Repetition  Frequency 

LPW 

Laser  Pulse  Width 

LRF/D 

Laser  Range  Finder/Designator 

LST 

Laser  Spot  Tracks 

LWR 

Laser  Warning  Receiver 

MCC 

Management  Command  and  Control 

MFD 

Multi-function  Display 

MMS 

Mast  Mounted  Sight 

MSB 

Multiple  Simulator  Environment 

MSS 

Modular  Simulator  System 

NATO 

North  Atlantic  Treaty  Organization 

NC« 

Nap  of  Earth 

NVG 

Night  Vision  Goggles 

NVPS 

Night  Vision  Pilotage  System 

OIW 

Out  the  Window 

PNVS 

Pilot  Night  Vision  System 

PRF 

Pulse  Repetition  Frequency 

PW 

Pulse  Width 

RADIAC 

Radiological 

RAM 

Random  Access  Memory 

RF 

Radio  Frequency 

RFD 

Remote  Fi^uoicy  Display 

RWA 

Rotary  Wing  Aircraft 

RWR 

Radar  Warning  Receiver 

RWS 

Radiological  Warning  System 

SAD 

Situational  Awareness  Display 

SCAS 

Stability  and  Control  Augmentation  Syst^ 

SOW 

Statement  of  Woric 

SS 

Simulator  System 

SSM 

Simulator  System  Module 
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STP  System  Test  Plan 

TADS  Target  Acquisition  Designation  Sight 

TAS  Target  Acquisition  System 

IBD  To  Be  Determined 

TBR  To  Be  Resolved 

TBS  To  Be  Supplied 

TIS  Thermal  Itnaging  System 

TNE  Tactical  and  Namral  Environment 

TCXZ  Tactical  Operations  Center 

TVS  Television  Sensor 

UHF  Ultra  High  Frequency 

V  Version 

VHF  Very  High  Frequency 

VNET  Virtual  Network 

6.2  Intended  Use.  The  SSM  is  one  of  three  modules  comprising  a  manned  simulation 
device  based  on  the  Modular  Simulator  System  (MSS)  architecture.  The  manned 
simulation  device(s)  consist  of  AH-64D  and  RAH-66  rotary  wing  aircraft  simulations  used 
to  explore  tactics,  doctrine  and  combat  system  development  issues  in  a  DIS  environment 
The  devices  are  not  intended  to  be  used  for  training  aircrews. 

6.2. 1  Mis.sion.s.  The  ARWA  devices  are  not  required  to  support  specific  missions.  The 
devices  will  be  used  for  experimentation  purposes.  The  adaptability  parameters  identified 
in  Appendix  B  will  be  used  to  modify  characteristics  of  the  device  as  required  by  the 
experiment  A  default  value  shall  be  defined  for  each  of  these  parameters  to  allow  for 
system  initialization.  The  default  values  shall  represent  a  nominal  aircraft  configuration. 

6.2. 1.1  Aircraft  Qperation.s.  Aircraft  operations,  tasks  and  procedures,  as 
applicable  to  the  models  within  the  SSM,  shall  be  simulated  to  the  level  of  fidelity  and 
factional  performance  defined  in  the  following  paragraphs. 

6.2. 1 . 1 . 1  Ground  Operations.  Ground  operations  shall  include  tactical  resupply  and 
rearming.  A  complex  ground  handling  model  is  not  required.  Ground  handling  shall 
consist  of  landing  the  aircraft  with  no  movement  along  Ae  grotmd.  Ground  oi^rations 
such  as  engine  start,  engine  run-up,  engine  and  aircraft  shutdown,  mission  loading,  pre¬ 
flight  and  post-flight  checkout  and  adjustment/calibration  procedures  shall  not  be  provided. 

6.2.1. 1.2  Takeoff/Climb/Cruise.  Simulation  of  the  transition  from  the  ground 
environment  to  flight,  including  aerodynamic  ground  effects,  shall  be  provided.  All 
regimes  of  aircraft  ffight  within  the  flight  envelope  of  the  aircraft  shall  be  modeled. 

6.2. 1 . 1 .3  Approach  and  Landing.  Simulation  of  the  transition  from  flight  to  ^ound 
environment,  including  aerodynamic  ground  effects,  shall  be  provided.  Simulation  of 
emergency  landing  operations  is  not  required. 

6.2. 1.1.4  Application  Specific  Flight  Operations.  Simulation  of  the  low  level, 
contour,  nap  of  the  earth,  masking  and  unmasking,  and  hovering  flight  shall  be  provided  to 
the  level  of  fidelity  defined  in  section  3  of  this  specification,  as  applicable  to  the  segments 
within  the  SSM. 


-  43  - 


ADST/TR  94-003276 


March  31,  1994 


6.2. 1.2  Mission  Specific  Operations.  The  SSM  shall  support  the  ARWA  device 
requirement  to  simulate  the  aircraft  fimctions  needed  to  move,  shoot,  communicate,  rearm, 
and  resupply  to  the  level  of  fidelity  defined  in  section  3  of  this  specification. 

6.2. 1.3  Multiple  Simulator  Operations.  The  SSM  shall  provide  an  interface  to  allow 
the  interoperability/networking  of  the  ARWA  device  to  other  simulation  devices.  The 
interface  shall  comply  with  the  Standards  for  Distributed  Interactive  Simulation,  version 
2.0.3.  The  ARWA  devices  to  the  DIS  network  shall  be  via  the  Environment  segment 


-  44  - 


ADST/TR  94-003276 


March  31,  1994 


APPENDIX  A 

10.  BATTLE  DAMAGE  AND  SYSTEM  MALFUNCTIONS 

10. 1  Introduction.  Hus  paragraph  defines  the  requirements  for  segments  in  the  ARWA 
for  the  simulation  of  battle  damage. 

10.2  General  Damage  Processing.  Damage  shall  arise  from  either  of  two  sources.  First, 
damage  may  result  from  collision  with  terrain,  culture,  or  other  vehicles.  In  the  ARWA, 
collision  shall  result  in  a  crash  and  loss  of  vehicle.  Second,  damage  may  result  from  the 
impact  and  detonation  of  ordinance  on  or  near  the  airframe.  The  ARWA  shall  simulate  the 
effects  of  these  combat  caused  damages. 

The  Environment  segment  shall  filter  the  impacts  and  detonations  occurring  in  the  DIS 
Environment  to  remove  from  consideration  those  which  cannot  affect  the  ARWA.  The 
Weapons  segment  shall  evaluate  the  remaining  impacts  and  detonations  for  effect  upon  the 
ARWA  device.  The  Weapons  segment  shall  assign  a  location  and  severity  percentage  (01 
to  1(X))  for  each  impact  and  detonation  judged  to  have  affected  the  ARWA  device.  The 
Weapons  segment  shall  broadcast  this  Damage  Assessment  message  to  all  segments.  Each 
segment  shtdl  simulate  the  effect  of  that  damage  assessment  upon  the  aircraft  systems  and 
mission  equipment  packages  associated  widi  it  The  Flight  Dynamics  segment  shall 
generate  an  impact  and  detonation  force  based  on  the  damage  assessment  message.  This 
impact  and  detonation  force  shall  affect  the  flight  path  of  the  vehicle  accordingly. 

The  two  types  of  damage  classifications  in  the  ARWA  are  total  and  fractional  system 
failures.  Total  system  f^ures  shall  be  a  complete  loss  of  capability  for  the  system.  The 
largest  incidence  of  total  system  failures  is  for  the  aircraft  electronic  systems.  Each 
segment  shall  inspect  the  damage  assessment  message  for  potential  damage  to  some  portion 
of  the  electronic  system  (antennas,  black  boxes,  etc.).  The  fractional  system  failures  shall 
simulate  a  partial  loss  of  capability  determined  by  the  segment  upon  receipt  of  the  damage 
assessment  message.  The  specific  degree  of  lost  capability  will  not  directly  be  the  damage 
assessment's  percentage.  Each  segment  shall  independently  model  the  effect  of  damage  in 
a  particular  location.  This  modeUng  shall  appropriately  address  the  potential  physical  or 
mechanical  manifestations  in  the  aircraft  or  mission  equipment  which  are  the  segment's 
responsibility  and  located  in  the  affected  airframe  zone. 

10.3  Damage  Location  Requirements.  The  Weapons  segment  shall  determine  the 
affected  location  on  the  airframe  of  an  impact  and  detonation  of  ordinance.  These  locations 
shall  represent  the  extremities  of  the  aircrrdt  (main  rotor,  tail  rotor,  and  landing  gear)  and  a 
breakdown  of  the  airframe  into  localized  "cubes."  The  cubes  shall  result  from  indexing 
along  the  three  airframe  axes  Oength,  height,  and  width).  The  length  indices  shall  be  nose, 
fuselage,  and  tail.  The  height  indices  shall  be  high  and  low.  The  width  indices  shall  be 
starboard  and  port  (from  the  pilot's  perspective).  More  specific  information  shall  not  be 
required.  The  Weapons  segment  shall  generate  a  severity  of  damage  expressed  as  a 
percentage,  according  to  the  specific  weapon,  warhead,  and  airframe.  Specific  knowledge 
by  other  segments  of  this  damage  assessment  process  shall  not  be  required. 

10.4  Segment  Battle  Damage  Requirements.  The  following  paragraphs  detail  the  damage 
simulation  requirements  for  each  segment 

10.4.1  Flight  Station  Segment  Damage  Requirements.  This  segment  shall  receive 

the  damage  assessment  message  from  the  Weapons  segment  for  simulation  of  the  resulting 
damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  damage  via  the  effects 
described  by  the  following: 
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(a)  Electrical  System  Failure 

(b)  Hydraulic  System  Leak 

(c)  Hydraulic  System  Failure 

10.4.2  Hieht  Controls  Segment  Damage  Requirements.  This  segment  shall  receive 
the  damage  assessment  message  from  the  Weapons  segment  for  simulation  of  the  resulting 
damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  effects  described  by  the 
following: 

(a)  Main  Rotor  Flight  Controls  Failure  (01  to  100%) 

(b)  Tail  Rotor  Flight  Controls  Failure  (01  to  100%) 

10.4.3  Flight  Dynamics  Segment  Damage  Requirements.  This  segment  shall 
receive  the  damage  assessment  message  from  the  Weapons  segment  for  simulation  of  the 
resulting  damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  effects  described 
by  the  following: 

(a)  Nose  Airframe  Distortion 

(b)  Tail  Airframe  Distortion 

(c)  Fuselage  Airframe  Distortion 

(d)  Landing  Gear  Airframe  Distortion 

(e)  Stub  Wing  Airframe  Distortion 

(f)  Tail  Rotor  Blade  Damage  (01  to  1(X)%) 

(g)  Main  Rotor  Blade  Damage  (01  to  1(X)%) 

10.4.4  Propulsion  Segment  Damage  Requirements.  This  segment  shall  receive  the 
damage  assessment  message  from  the  Weapons  segment  for  simidation  of  the  resulting 
damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  effects  described  by  the 
following: 

(a)  Fuel  System  Leak  (01  to  100%) 

(b)  Fuel  System  Failure 

(c)  Transmission  Damage  (01  to  100%) 

(d)  Turbine  Damage  (01  to  100%) 

10.4.5  Navigation/Communicatjon  Segment  Damage  Requirements.  This  segment 
shall  receive  the  damage  assessment  message  from  the  Weapons  segment  for  simulation  of 
the  resulting  damage  to  its  aircraft  systems.  This  segment  shaU  simulate  the  effects 
described  by  the  following: 

(a)  Dopplo:  Navigation  System  Failure 
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(b)  Inteicom  System  Failure 

(c)  Radio  Systems  (VHF,  UHF,  HF)  Failures 

(d)  Air  Data  SenscNrs  Failure 

(e)  Airborne  Target  Handover  System  Failure 

10.4.6  Weapons  Segment  Damage  Reouirements.  This  segment  shaU  receive  the 
damage  assessment  message  from  die  Weapons  segment  for  simulation  of  the  resulting 
damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  effects  described  by  the 
following: 

(a)  Incidental  Detonation  (Ownship  weapons) 

(b)  Incidental  Jettison  (Ownship  weapons) 

(c)  Hre  Control  System  Failure 

(d)  Gun  Turret  System  Failure 

10.4.7  Sensor  Control  Segment  Damage  Requirements.  This  segment  shall  receive 
the  damage  assessment  message  from  the  Weapons  segment  for  simulation  of  the  resulting 
damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  effects  described  by  the 
following: 

(a)  Night  Sight  Sensors  System  Failure 

(b)  Day  Sight  Sensors  System  Failure 

(c)  Laser  Sensors  System  Failure 

(d)  Integrated  Helmet  Display  System  Failure 

(e)  Autotracker  System  Failure 

(f)  Turret  Steering  System  Failure 

10.4.8  Aircraft  Survivability  Equipment  Damage  Requirements.  This  segment 
shall  receive  the  damage  assessment  message  from  the  Weapons  segment  for  simulation  of 
the  resulting  damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  effects 
described  by  the  following: 

(a)  Radar  Warning  System  Failure 

(b)  Laser  Warning  System  Failure 

(c)  Radiological  Warning  System  Failure 

(d)  Chemical  Warning  System  Failure 

(e)  Radar  Jamming  System  Failure 
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(f)  Infra-ied  Jamming  System  Failure 

(g)  Chaff  System  Failure 

(h)  Flares  System  Failure 

0.4.9  Physical  Cues  Segment  Damage  Requirements.  This  segment  shall  receive  the 
damage  assessment  message  from  die  Weapons  segment  for  simulation  of  the  resulting 
damage  to  its  aircraft  systems.  This  segment  shall  simulate  the  effects  described  by  the 
following: 

(a)  Wind  Noise  from  Airframe  Damage  (01  to  100%) 

(b)  Impact  and  E)etonation  Noise  (01  to  lOO%) 

10.4.10  Control  Segment  Damage  Reouirements.  Simulation  of  damage  shall  not  be 
required  for  this  segment 

10.4.11  Environment  Segment  Damage  Requirements.  This  segment  shall  translate 
the  damage  assessment  message  to  describe  to  the  DIS  the  effect  of  the  impact  and 
detonation  on  the  ownship. 
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APPENDIX  B 

20.  SIMULATOR  ADAPTABILITY 

20.1  Introduction.  The  ARWA  SS  adaptability  requirement  is  to  support  convenient 
modification  of  significant  simulation  parameters  in  order  to  permit  experiments  with 
different  weapon  system  characteristics.  The  adaptability  problem  may  be  divided  into  five 
levels  of  scope: 

(a)  Parameter  Tuning  (during  simulation), 

(b)  Parameter  Estimation  (off-line), 

(c)  Model  Modification  (new  baseline),  and 

(d)  New  Model  (off-site). 

This  appendix  only  addresses  parameter  tuning  and  parameter  estimation.  Model 
modification  and  new  model  creation  involves  the  editing  of  simulation  source  code,  and 
therefore  is  the  domain  of  the  ARWA  Development  subsystem. 

20.2  Parameter  Adaptability.  The  following  paragraphs  detail  the  requirements  for 
parameter-oriented  adaptability,  i.e.,  paraineter  tuning  and  parameter  estimation.  Parameter 
estimation  shall  be  the  process  by  which  an  experimenter  defines  a  baseline  set  of 
simulation  parameters  for  later  execution.  It  shall  1^  an  off-line  process,  i.e.,  access  to  an 
ARWA  Device  shall  not  be  required.  Parameter  tuning  shall  be  the  process  by  which  an 
experimenter  reffnes  his  initial  parameter  estimates  while  the  simulation  is  in  progress. 
Parameter  estimation  and  parameter  tuning  shall  permit  access  to  the  same  set  of  editable 
parameters.  Parameter  tuning  shall  provide  a  superset  of  the  parameter  estimation 
functions.  A  specific  set  of  parameter  values  for  the  simulation  shall  be  identified  for 
initialization  of  the  ARWA  device.  These  values  shall  serve  as  default  values  for  the 
adaptability  parameters.  Each  segment  shall  initialize  to  these  default  values  unless 
requested  to  do  otherwise  by  the  Control  segment.  The  default  values  shall  represent  a 
normal  or  nominal  value  for  Ae  aircraft 

20.3  Session  Manager  Adaptability.  This  paragraph  shall  address  the  specific  role  of  the 
Session  Manager  in  parameter  adaptability. 

The  Session  Manager  shall  provide  an  interface  for  users  to  access  and  edit  the  parameters 
defined  in  paragraph  20.4  for  each  ARWA  Device.  This  interface  shall  provide  convenient 
tools  that  permit  the  user  to  access  and  modify  adaptability  parameters  for  a  given  ARWA 
device.  Ilie  interface  shall  permit  the  user  to  uniquely  create,  name,  rename,  and  delete 
adaptability  parameters  individually  or  as  a  set  The  Session  Manager  shall  query  the  user 
about  saving  parameter  data  sets  upon  shut  down  of  the  affected  ARWA  Devices  for  future 
experiments. 

The  Session  Manager  shall  display  default  values  and  the  current  value  for  every  parameter 
to  the  user.  The  Session  Manager  shall  permit  the  user  to  edit  from  these,  or  load  a  saved 
data  set  to  insert  new  values  into  an  exercise.  The  Session  Manager  shall  provide  a 
structured  interface  to  the  parameters  to  ease  tl»  experimenter's  task  in  selection  and  editing 
of  the  parameters.  In  the  case  of  parameter  tuning,  the  Session  Manager  shall  not 
implement  a  given  parameter  edit  immediately.  The  Session  Manager  shall  record  the  series 
of  edits  (for  estimation  or  tutting)  during  a  edit  session.  The  Session  Manager  shall  permit 
undoing  the  edits  via  reload  of  the  last  parameter  data  set  The  Session  Manager  shall 
permit  die  us  r  to  save  the  edited  data  set  at  any  time.  In  the  case  of  parameter  tutting,  the 
Session  Manager  shall  permit  the  user  to  introduce  the  edit  series  into  the  simulation. 
Introduction  of  changes  to  adaptability  parameter  values  shall  require  a  freeze  and 
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realignment  of  the  affected  ARWA  Device.  The  Session  Manager  shall  allow  the  user  to 
freeze  the  entire  simulation  exercise  or  just  the  ARWA  Device  affected  by  the  parameter 
tuning,  for  the  purposes  of  introducing  the  new  data  set  Introduction  of  the  data  set  shsdl 
consist  of  sending  the  data  s^  to  the  affected  ARWA  Device's  Envirmunent  segment  via  the 
DIS  Network,  and  issuance  of  a  freeze  and  a  alignment  state  transition  command.  All  DIS 
data  transmissions  shall  use  the  simulation  management  Protocol  Data  Units  (PDUs)  as 
defmed  in  DIS  standard  2.0,  version  3. 

20.4  ARWA  Device  Adaptability.  The  tequironents  for  parameter  adaptability  vary  from 
segment  to  segment  within  the  ARWA  Device.  The  following  paragraphs  det^  the 
parameter  ad^tability  requirements  by  segment 

20.4.1  Flight  Station  Segment  Adaptability  Requirements.  The  flight  station 
segment  shall  provide  parameters  for  adaptability.  The  parameters  shall  allow  for  the 
adjustment  of  fuel  capacity  and  fueling  time. 

20.4.2  Flight  Controls  Segment  Adaptability  Requirements.  The  flight  controls 
segment  shall  provide  parameters  for  adaptability.  The  parameters  shall  allow  for  the 
sensitivity  adjustment  for  the  cyclic  control  and  collective  control. 

20.4.3  Flight  Dynamics  Segment  Adaptability  Requirements.  The  flight  dynamics 
segment  shall  provide  parameters  for  adaptability.  The  parameters  shall  allow  for  the 
adjustment  of  pitch  limits,  roll  limits,  yaw  limits,  turning  radius,  main  rotor  lift 
performance,  tail  rotor  lift  performance,  and  weight  limits. 

20.4.4  Propulsion  Segment  Adaptability  Requirements.  The  propulsion  segment 
shall  provide  parameters  for  adaptability.  The  parameters  shall  allow  for  the  adjustment  of 
fuel  bum  rate  and  maximum  turbine  speed. 

20.4.5  Nav/Comm  Segment  Adaptability  Requirements.  The 
navigation/communication  segment  shall  provide  parameters  for  adaptability.  The 
parameters  shall  allow  for  the  adjustment  of  position  error,  bearing  error,  and  attitude  error 
for  the  navigation  system. 

20.4.6  Weapons  Segment  Adaptability  Requirements.  The  weapons  segment  shall 
provide  parameters  for  adaptability.  Figure  20.4.6-1  illustrates  the  weapons  segment 
parameters. 

20.4.7  Sensor  Segment  Adaptability  Requirements.  The  sensor  segment  shall 
provide  parameters  for  adaptability.  The  parameters  shall  allow  for  the  adjustment  of 
NVPS  and  TAS  turret  slew  rates;  NVPS  and  TAS  gimbal  limits;  NVPS,  TAS  TV,  and 
TAS  FLIR  FOV  limits;  maximum  target  detection  range;  maximum  target  classification 
range;  and  laser  range  error. 

20.4.8  ASE  Segment  Adaptability  Requirements.  The  aircraft  survivability 
equipment  segment  shall  provide  parameters  for  adaptability.  Figure  20.4.8-1  illustrates 
the  aircraft  survivability  equipment  segment  parameters. 
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Figure  20,4.6-1  Weapons  Segment  Adaptability  Parameters 
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Figure  20.4.8-1  Aircraft  Survivability  Equipment  Adaptability  Parameters 
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20.4.9  Physical  Cues  Segment  Adaptability  Requirements.  The  physical  cues 
segment  shall  not  be  lequiied  to  proyide  any  parameter  ad£4)tability. 

20.4.10  Visual  Module  Adaptability  Requirements.  The  yisual  segment  shaU 
proyide  parameters  for  adaptability. 

20.4.11  Control  .Segment  Adaptability  Requirements.  The  control  segment  sh^  not 
be  required  to  proyide  any  parameter  adaptability.  Howeyer,  the  control  segment  is  the 
central  controller  of  parameter  adaptability  for  the  ARWA  Deyice.  The  control  segment 
shall  receiye  requests  to  change  adaptability  parameter  yalues  from  the  Enyironment 
segment  These  requests  will  be  receiyed  from  the  Session  Manager  subsystem  by  the 
Enyironment  segment  yia  the  DIS  network  interface.  The  Enyironment  will  pass  these 
requests  to  the  Control  segment  yia  the  VNET.  The  Control  segment  shall  control  the 
insertion  of  the  new  adaptability  parameter  yalue  into  the  exercise  to  affect  the  desired 
result. 

20.4.12  Enyironment  Segment  Adaptability  Requirements.  The  Enyvonment 
segment  shall  not  be  required  to  proyide  any  parameter  adaptability.  The  Enyironment 
segment  shall  receiye  DIS  Data  PDUs  from  the  Session  Manager  subsystem  when  an 
adaptability  parameter  change  is  required.  The  Environment  segment  shall  pass  the 
adaptability  parameter  change  request  to  the  Control  segment  for  implementation. 
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APPENDIX  C 

30.  SIMULATION  DATA  LOGGER 

30. 1  Introduction.  The  ARWA  SS  data  logger  shall  provide  an  after-action  capability  to 
analyze  the  results  of  a  simulation  game.  The  only  requirement  for  data  logging  shall  be 
recording  of  BDS-D  Network  traffic.  The  BDS-D  Network  provides  the  information  flow 
between  and  about  entities  in  the  simulation  game. 

30.2  Simulation  Manager  Data  Logger.  The  simulation  manager  shall  provide  the 
ARWA  SS  data  logger  function.  Iiutiation  of  a  data  logging  session  shall  require  the 
specification  of  the  level  of  messages  to  record  as  well  as  specification  of  the  group  of 
simulation  entities. 

The  data  logger  function  shall  support  the  recording  of  BDS-D  network  traffic  at  three 
levels.  The  function  shall  permit  die  all  BDS-D  messages.  The  function  shall  permit  the 
user  to  record  all  BDS-D  messages  of  a  specified  type.  The  function  shall  i^rmit  the  user 
to  record  all  BDS-D  messages  all  a  specified  type  when  a  specified  field  within  the  message 
takes  on  a  specified  value. 

The  data  logger  function  shall  support  the  recording  level  specification  for  three  different 
groups  of  BDS-D  network  traffic  in  tiitee  different  groups.  The  function  shall  permit  the 
user  to  specify  the  group  of  all  entities.  The  function  shall  permit  the  user  to  specify  the 
group  of  all  entities  of  a  certain  class(e.g.,  AH-64D,  RAH-66,  etc.).  Finally,  the  function 
^all  permit  the  user  to  specify  the  group  of  a  single  entity. 

The  simulation  manager  shall  provide  a  convenient  mechanism  for  specifying  the  various 
components  of  the  data  logger  specification.  It  shall  mark  each  set  of  recordings  with  an 
identification  of  the  kind  of  recordings.  It  shall  provide  the  necessary  memory  for  storing 
the  recording  messages.  It  shall  provide  tools  for  inspection  and  analysis  of  the  recorded 
messages.  The  specific  requirements  for  the  simulation  manager  are  found  in  Volume  I  of 
this  specification. 

30.3  ARWA  Device  Data  Logger.  The  ARWA  SS  requir^ent  to  support  data  logging  is 
to  record  BDS-D  netwoik  traffic.  This  requirement  is  entirely  allocate  to  the  Simulation 
Manager.  Therefore,  there  is  no  data  logging  requirement  specifled  for  the  individual 
ARWA  Devices. 
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